| 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: | 482C53A6.2030802@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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 http://www.postgresql.org/docs/faqs.TODO.html 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
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew Wakeling | 2008-05-15 15:17:29 | Re: I/O on select count(*) |
| Previous Message | Heikki Linnakangas | 2008-05-15 15:08:36 | Re: I/O on select count(*) |