On Wed, Nov 23, 2011 at 9:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.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 http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
