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

Re: I/O on select count(*)

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Greg Smith" <gsmith(at)gregsmith(dot)com>,"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: I/O on select count(*)
Date: 2008-05-15 15:15:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Alvaro Herrera wrote:
> Greg Smith escribió:
>> On Thu, 15 May 2008, Pavan Deolasee wrote:
>>> I had suggested in the past that whenever we set hint bits for a tuple, 
>>> we should check all other tuples in the page and set their hint bits 
>>> too to avoid multiple writes of the same page. I guess the idea got 
>>> rejected because of lack of benchmarks to prove the benefit.
>> From glancing at I got the  
>> impression the idea was to have the background writer get involved to 
>> help with this particular situation.
> The problem is that the bgwriter does not understand about the content
> of the pages it is writing -- they're opaque pages for all it knows.  So
> it cannot touch the hint bits.

We know what kind of a relation we're dealing with in ReadBuffer, so we 
could add a flag to BufferDesc to mark heap pages.

> If we had the bitmask in a separate map fork, this could be cheap.

I don't buy that. The point of a hint bit is that it's right there along 
with the tuple you're looking at. If you have to look at a separate 
buffer, you might as well just look at clog.

   Heikki Linnakangas

In response to


pgsql-performance by date

Next:From: Matthew WakelingDate: 2008-05-15 15:17:29
Subject: Re: I/O on select count(*)
Previous:From: Heikki LinnakangasDate: 2008-05-15 15:08:36
Subject: Re: I/O on select count(*)

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