From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Visibility map thoughts |
Date: | 2007-11-05 18:25:00 |
Message-ID: | 1194287100.4315.120.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2007-11-05 at 09:52 +0000, Heikki Linnakangas wrote:
> Reducing VACUUM time is important, but the real big promise is the
> ability to do index-only-scans.
Have you thought about how index-only scans work work? Seems like we
need a rough plan for that before we go and build the visibility map,
your other notes for which sound very good.
I'm thinking that looking in the visibility map will have a cost also,
so how will we know whether to bother looking? I'm assuming that we
won't want to do that lookup in all cases, since it could easily just
add pathlength and contention in the normal OLTP case. Presumably there
would be a test in the planner to see if an index-only plan was
possible?
I'm racking my brain trying to think of a query that will benefit from
index-only scans without specifically creating covered indexes. Apart
from count(*) queries and RI lookups. I can't see RI lookups being much
cheaper with this technique, do you see something there?
ISTM that it would make most sense to do it during BitmapIndex scans.
Specifically, as an intermediate step between BitmapIndex scan and
BitmapHeap scan. That would be fairly likely to be a win in most cases
because the bitmaps should compare easily and the amortised cost per row
is likely to be very small, even if no heap lookups are avoided.
Anyway, just a few initial thoughts.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-11-05 18:31:39 | Re: pg 8.3beta 2 restore db with autovacuum report |
Previous Message | Zdenek Kotala | 2007-11-05 18:21:38 | Is necessary to use SEQ_MAXVALUE in pg_dump? |