From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adam Brusselback <adambrusselback(at)gmail(dot)com> |
Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Surprising benchmark count(1) vs. count(*) |
Date: | 2019-09-19 21:36:35 |
Message-ID: | 15291.1568928995@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Adam Brusselback <adambrusselback(at)gmail(dot)com> writes:
> It would be nice if Postgres optimized this case though because it is
> really really common from what i've seen.
Since the introduction of the "planner support function" infrastructure,
it'd be possible to do this without it being a completely ugly kluge:
we could put the logic for it into a planner support function attached
to count(any). Currently planner support functions are only called for
regular functions, but we could certainly envision adding the ability to
do it for aggregates (and window functions too, why not).
I'm not particularly planning to do that myself, but if someone else
wants to write a patch, have at it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Luís Roberto Weck | 2019-09-19 22:27:34 | Re: Slow query on a one-tuple table |
Previous Message | Luís Roberto Weck | 2019-09-19 20:41:19 | Re: Slow query on a one-tuple table |