From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(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:49:32 |
Message-ID: | 20080515154932.GB8221@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Heikki Linnakangas escribió:
> Alvaro Herrera wrote:
>> 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.
Hmm, I was thinking that it would need access to the catalogs to know
where the tuples are, but that's certainly not true, so perhaps it could
be made to work.
>> 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.
True -- I was confusing this with the idea of having the tuple MVCC
header (xmin, xmax, etc) in a separate fork, which would make the idea
of index-only scans more feasible at the expense of seqscans.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-05-15 15:52:32 | Re: I/O on select count(*) |
Previous Message | Joshua D. Drake | 2008-05-15 15:38:18 | Re: which ext3 fs type should I use for postgresql |