From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Wood <hexexpert(at)comcast(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: On the need for a snapshot in exec_bind_message() |
Date: | 2018-09-05 22:45:52 |
Message-ID: | 23144.1536187552@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Wood <hexexpert(at)comcast(dot)net> writes:
>>> exec_bind_message()
>>> PushActiveSnapshot(GetTransactionSnapshot());
>>>
>>> If there were no input functions, that needed this, nor reparsing or
>>> reanalyzing needed, and we knew this up front, it'd be a huge win.
>> Unfortunately, that's not the case, so I think trying to get rid of
>> this call is a nonstarter.
> Queries stop getting re-optimized after 5 times, unless better plans are to be had. In the absence of schema changes or changing search path why is the snapshot needed?
The snapshot has little to do with the query plan, usually. It's about
what view of the database the executed query will see, and particularly
about what view the parameter input functions will see, if they look.
You could maybe argue that immutable input functions shouldn't need
snapshots, but there are enough not-immutable ones that I don't think
that gets you very far. In any case, we'd still need a snapshot for
query execution. The set of queries that could possibly never need
a snapshot at all is probably not large enough to be interesting.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-05 22:54:38 | Re: On the need for a snapshot in exec_bind_message() |
Previous Message | Chapman Flack | 2018-09-05 22:38:01 | Re: *_to_xml() should copy SPI_processed/SPI_tuptable |