Tom Lane wrote:
> Andrew Dunstan writes:
> > On 02/01/2011 05:47 PM, Bruce Momjian wrote:
> >> Tom Lane wrote:
> >>> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
> >>> and it's difficult to see how to get any real improvement without tackling
> >>> that.
>
> >> Do we
On 2/1/2011 5:47 PM, Bruce Momjian wrote:
Do we want a TODO about optimizing COUNT(*) to avoid aggregate
processing overhead?
Definitely not. In my opinion, and I've seen more than a few database
designs, having count(*) is almost always an error.
If I am counting a large table like the one
Andrew Dunstan writes:
> On 02/01/2011 05:47 PM, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
>>> and it's difficult to see how to get any real improvement without tackling
>>> that.
>> Do we want a TODO about optimizing COU
On 02/01/2011 05:47 PM, Bruce Momjian wrote:
Tom Lane wrote:
At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
and it's difficult to see how to get any real improvement without tackling
that. Rather than apply the patch shown above, I'm tempted to think about
hard-wiri
Tom Lane wrote:
> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
> and it's difficult to see how to get any real improvement without tackling
> that. Rather than apply the patch shown above, I'm tempted to think about
> hard-wiring COUNT(*) as a special case in nodeAgg.c
