Skip site navigation (1) Skip section navigation (2)

Re: Hardware/OS recommendations for large databases (

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 (view raw or flat)
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


In response to

pgsql-performance by date

Next:From: Luke LonerganDate: 2005-11-24 17:07:40
Subject: Re: Hardware/OS recommendations for large databases (
Previous:From: Tom LaneDate: 2005-11-24 16:25:28
Subject: Re: Hardware/OS recommendations for large databases (

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group