From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "Wirch, Eduard" <eduard(dot)w(at)smart-host(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: PostgreSql: Canceled on conflict out to old pivot |
Date: | 2023-12-01 00:31:38 |
Message-ID: | 20231201003138.7riixfp4mn5vmcck@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-11-30 18:51:35 -0500, Tom Lane wrote:
> On what grounds do you assert that? Operations on shared catalogs
> are visible across databases. Admittedly they can't be written by
> ordinary DML, and I'm not sure that we make any promises about DDL
> writes honoring serializability. But I'm unwilling to add
> "optimizations" that assume that that will never happen.
I'd say the issue is more that it's quite expensive to collect the
information. I tried in the past to make the xmin computation in
GetSnapshotData() be database specific, but it quickly shows in profiles, and
GetSnapshotData() unfortunately is really performance / scalability critical.
If that weren't the case, we could check a shared horizon for shared tables,
and a non-shared horizon otherwise.
In some cases we can compute a "narrower" horizon when it's worth the cost,
but quite often we lack the necessary data, because various backends have
stored the "global" xmin in the procarray.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tommy Pavlicek | 2023-12-01 00:44:40 | Re: [PATCH] ltree hash functions |
Previous Message | Andres Freund | 2023-12-01 00:14:27 | Re: Something seems weird inside tts_virtual_copyslot() |