Re: the big picture for index-only scans

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

In response to

Responses

Browse pgsql-hackers by date

  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