Re: On the need for a snapshot in exec_bind_message() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On the need for a snapshot in exec_bind_message()
Date
Msg-id 23144.1536187552@sss.pgh.pa.us
Whole thread Raw
In response to Re: On the need for a snapshot in exec_bind_message()  (Daniel Wood <hexexpert@comcast.net>)
Responses Re: On the need for a snapshot in exec_bind_message()  (Andres Freund <andres@anarazel.de>)
Re: On the need for a snapshot in exec_bind_message()  (Daniel Wood <hexexpert@comcast.net>)
List pgsql-hackers
Daniel Wood <hexexpert@comcast.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
orchanging 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


pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Next
From: Andres Freund
Date:
Subject: Re: On the need for a snapshot in exec_bind_message()