From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: the big picture for index-only scans |
Date: | 2011-08-19 14:17:04 |
Message-ID: | CA+TgmoZzY9cbJLBn-TZYUM=zV+6QBWLOYUGzms_9Sxc4o-W64w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 19, 2011 at 9:19 AM, Gokulakannan Somasundaram
<gokul007(at)gmail(dot)com> wrote:
> The fact that the
> proposal is for crash safe visibility map, to become a default package of
> any Postgresql table will definitely have wide ranging implications on OLTP
> performance.
Well, that would certainly be alarming if true, but I don't think it
is. As far as I can see, the overhead of making the visibility map
crash-safe is just (1) a very small percentage increase in the work
being done by VACUUM and (2) a slight possibility of extra work done
by a foreground process if the visibility map bit changes at almost
exactly the same time the process was about to insert, update, or
delete a tuple.
If someone comes up with a test where this overhead is enough to
measure, then we might need to rethink our whole approach. Maybe we
would make it an optional feature, or maybe we would just rip it out
and start over with some sort of redesign, or maybe we would look for
other optimizations to counterbalance the additional overhead. I
don't know. But as far as I can see you're hypothesizing without
evidence.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-19 14:20:46 | Re: [v9.1] sepgsql - userspace access vector cache |
Previous Message | Robert Haas | 2011-08-19 14:06:55 | Re: [v9.1] sepgsql - userspace access vector cache |