Re: Synchronized snapshots versus multiple databases

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Synchronized snapshots versus multiple databases
Date: 2011-10-21 17:40:14
Message-ID: 53C592A2-9044-4954-8C60-057E5BCC4050@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Oct21, 2011, at 19:09 , Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> On Oct21, 2011, at 17:36 , Tom Lane wrote:
>>> 3. Remove the optimization that lets GetOldestXmin ignore XIDs outside
>>> the current database. This sounds bad, but OTOH I don't think there's
>>> ever been any proof that this optimization is worth much in real-world
>>> usage. We've already had to lobotomize that optimization for walsender
>>> processes, anyway.
>
>> Hm, we've told people who wanted cross-database access to tables in the
>> past to either
>
>> * use dblink or
>
>> * not split their tables over multiple databases in the first place,
>> and to use schemas instead
>
>> If we remove the GetOldestXmin optimization, we're essentially reversing
>> course on this. Do we really wanna go there?
>
> Huh? The behavior of GetOldestXmin is purely a backend-internal matter.
> I don't see how it's related to cross-database access --- or at least,
> changing this would not represent a significant move towards supporting
> that.

AFAIR, the performance hit we'd take by making the vacuum cutoff point
(i.e. GetOldestXmin()) global instead of database-local has been repeatedly
used in the past as an against against cross-database queries. I have to
admit that I currently cannot seem to find an entry in the archives to
back that up, though.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-10-21 17:41:03 Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces
Previous Message Robert Haas 2011-10-21 17:20:46 Re: So, is COUNT(*) fast now?