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

Re: Much Ado About COUNT(*)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Much Ado About COUNT(*)
Date: 2005-01-13 15:29:16
Message-ID: 9210.1105630156@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-patches
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> The ugly part of this is that clearing the bit is not like setting a
>> hint bit, ie it's not okay if we lose that change.  Therefore, each
>> bit-clearing would have to be WAL-logged.  This is a big part of my
>> concern about the cost.

> Yep, that was my concern too.  My feeling is that once you mark the
> tuple for expiration (update/delete), you then clear the index bit. 
> When reading WAL on recovery, you have to clear index bits on rows as
> you read expire information from WAL.  I don't think it would require
> extra WAL information.

Wrong.  The WAL recovery environment is not capable of executing
arbitrary user-defined functions, therefore it cannot compute index
entries on its own.  The *only* way we can do this is if the WAL record
stream tells exactly what to do and which physical tuple to do it to.

			regards, tom lane

In response to

Responses

pgsql-announce by date

Next:From: D'Arcy J.M. CainDate: 2005-01-13 18:22:42
Subject: Re: Much Ado About COUNT(*)
Previous:From: Bruce MomjianDate: 2005-01-13 14:04:46
Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:From: Greg StarkDate: 2005-01-13 15:50:22
Subject: Re: [HACKERS] Much Ado About COUNT(*)
Previous:From: Csaba NagyDate: 2005-01-13 14:48:51
Subject: Re: [HACKERS] Much Ado About COUNT(*)

pgsql-patches by date

Next:From: David FetterDate: 2005-01-13 17:26:57
Subject: Re: Returning multiple cursors from PL/PgSQL
Previous:From: Bruce MomjianDate: 2005-01-13 14:04:46
Subject: Re: Much Ado About COUNT(*)

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