From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, Luke Lonergan <llonergan(at)greenplum(dot)com>, stange(at)rentec(dot)com, Dave Cramer <pg(at)fastcrypt(dot)com>, Joshua Marsh <icub3d(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Hardware/OS recommendations for large databases ( |
Date: | 2005-11-24 16:40:21 |
Message-ID: | 877jayknii.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Last I heard the reason count(*) was so expensive was because its state
> > variable was a bigint. That means it doesn't fit in a Datum and has to be
> > alloced and stored as a pointer. And because of the Aggregate API that means
> > it has to be allocated and freed for every tuple processed.
>
> There's a hack in 8.1 to avoid the palloc overhead (courtesy of Neil
> Conway IIRC).
ah, cool, missed that.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2005-11-24 17:07:40 | Re: Hardware/OS recommendations for large databases ( |
Previous Message | Tom Lane | 2005-11-24 16:25:28 | Re: Hardware/OS recommendations for large databases ( |