Hello!
I was thinking the same thing once - and you may
see db989184cda7f4aa1ff764cca96142029e7e093b for the special comment about
that :)
https://github.com/postgres/postgres/commit/db989184cda7f4aa1ff764cca96142029e7e093b
Tom Lane writes:
> Andy Fan writes:
>> Tom Lane writes:
>>> Many years ago, we committed a patch to do exactly that. We had
>>> to back it out again because it broke too many real-world scenarios.
>>> I'm too lazy to search the archives for you, but you might be able
>>> to find the commit and
Andy Fan writes:
> Tom Lane writes:
>> Many years ago, we committed a patch to do exactly that. We had
>> to back it out again because it broke too many real-world scenarios.
>> I'm too lazy to search the archives for you, but you might be able
>> to find the commit and revert by searching the g
Tom Lane writes:
> Andy Fan writes:
>> My question is why can't we share the same snapshot for the 2 cases?
>> parser & planner requires Catalog Snapshot which should be the
>> latest one, but in the above case, looks the executor can reuse it as
>> well. Is there anything I missed?
>
> Many ye
Andy Fan writes:
> My question is why can't we share the same snapshot for the 2 cases?
> parser & planner requires Catalog Snapshot which should be the
> latest one, but in the above case, looks the executor can reuse it as
> well. Is there anything I missed?
Many years ago, we committed a patc
Hi,
When I run "SELECT * FROM pg_class LIMIT 1"; then postgresql
run GetSnapshotData twice, one is
/*
* Set up a snapshot if parse analysis/planning will need one.
*/
if (analyze_requires_snapshot(parsetree))
{
PushActiveSnapshot(GetTransactionSnapshot());
snapshot_set = true
