News for hackers. Stuff that matters.
Re:PostgreSQL Count(*) Performance Improvements by sitharus on Wednesday April 10, 2019 @10:51PM (#19630756)
I'm not sure I understand your statement. On databases without an intrinsic row count property the only way to find the row count is to go to every page and count the rows there. The query planner will use the same plan for both `count(*)` and `count(1)`.
Re:PostgreSQL Count(*) Performance Improvements by znep on Wednesday April 10, 2019 @11:04PM (#19630814)
An interesting postgres oddity I ran into a few years ago that isn't about counting but is in a similar arena is how under very specific circumstances, "SELECT *" is significantly faster than "SELECT one_column" despite the conventional and normally well advised advice that you should only select the columns you need.

See https://www.postgresql.org/message-id/CAN1FPGN1ynBj3m1DMszc9... and Tom Lane's followup for details.

Re:PostgreSQL Count(*) Performance Improvements by hinkley on Thursday April 11, 2019 @01:39AM (#19631451)
Not according to that blurb. There have been other databases where count(1) was much faster. Here they are saying that in Postgres, count(1) is slower because star is treated as no arguments, and count(1) is more complex.
Re:PostgreSQL Count(*) Performance Improvements by laurenz_albe on Thursday April 11, 2019 @05:31AM (#19632402)
That is not what "they" are saying. count(1) and count(*) are equally fast because they are doing the same thing.