Skip site navigation (1) Skip section navigation (2)

Re: Not HOT enough

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Not HOT enough
Date: 2011-11-23 22:43:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Nov 23, 2011 at 9:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> My patch actually improves the speed of snapshots, rather than slowing
>> them as Tom's would.
> It can be arbitrarily fast if it doesn't have to get the right answer.

(LOL) - laughing with you

> Unfortunately, you're not producing the right answer.  You can not
> exclude XIDs in other databases from the snapshot, at least not unless
> you know that the snapshot will not be used for examining any shared
> catalogs ... and GetSnapshotData certainly cannot know that.
> I think that the idea of computing a different cutoff on the
> probably-rare occasions where we need to prune a shared catalog page
> has some merit, but the change you are currently proposing to
> GetSnapshotData flat out does not work.

All true, but I already said that myself in a direct reply to you 2 hours ago.

And I proposed a solution, which was to use SnapshotNow as an override
for user queries against shared catalog tables.

Computing two cutoffs is overkill for the rare event of pruning a
shared catalog page. I did think of that already and its not a good
solution. I'm tempted by the idea of getting rid of multiple databases
altogether. The hassle of supporting that feature far outweighs the
fairly low benefit.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-11-23 22:47:39
Subject: Re: Not HOT enough
Previous:From: Magnus HaganderDate: 2011-11-23 22:36:57
Subject: Snapshot build updates

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group