From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | 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 14:41:06 |
Message-ID: | 20080515144106.GA8221@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
I agree with Pavan that it's likely that setting hint bits in batches
instead of just for the tuple being examined is a benefit. However,
it's perhaps not so good to be doing it in a foreground process, because
you're imposing extra cost to the client queries which we want to be as
fast as possible. Perhaps the thing to do is have a "database-local
bgwriter" which would scan pages and do this kind of change ...
a different kind of process to be launched by autovacuum perhaps.
If we had the bitmask in a separate map fork, this could be cheap.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-15 14:52:58 | Re: I/O on select count(*) |
Previous Message | Jeffrey Baker | 2008-05-15 13:56:24 | Re: Update performance degrades over time |