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

Re: Hardware/OS recommendations for large databases (

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: 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:25:28
Message-ID: 14286.1132849528@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
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).

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Greg StarkDate: 2005-11-24 16:40:21
Subject: Re: Hardware/OS recommendations for large databases (
Previous:From: Greg StarkDate: 2005-11-24 16:00:25
Subject: Re: Hardware/OS recommendations for large databases (

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