| From: | Marti Raudsepp <marti(at)juffo(dot)org> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Kääriäinen Anssi <anssi(dot)kaariainen(at)thl(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "postgres(at)cybertec(dot)at" <postgres(at)cybertec(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: index-only scans |
| Date: | 2011-09-25 18:43:05 |
| Message-ID: | CABRT9RCszX41+PDAx6j4ctQJ3YjfLCENRzJ5mb06PG8GBP15Yw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Aug 14, 2011 at 00:31, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> That is somewhat compensated by the fact that tuples that are accessed more
> often are also more likely to be in cache. Fetching the heap tuple to check
> visibility is very cheap when the tuple is in cache.
>
> I'm not sure how far that compensates it, though. I'm sure there's typically
> nevertheless a fairly wide range of pages that have been modified since the
> last vacuum, but not in cache anymore.
Would it make sense to re-evaluate the visibility bit just before a
page gets flushed out from shared buffers? On a system with no long
transactions, it seems likely that a dirty page is already all-visible
by the time bgwriter (or shared buffers memory pressure) gets around
to writing it out. That way we don't have to wait for vacuum to do it
and would make your observation hold more often.
Regards,
Marti
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Berkus | 2011-09-25 19:04:49 | Re: Range Types - symmetric |
| Previous Message | Joshua Berkus | 2011-09-25 18:39:42 | Re: unite recovery.conf and postgresql.conf |