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 13880.1536176390@sss.pgh.pa.us
Whole thread Raw
In response to 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()  (Daniel Wood <hexexpert@comcast.net>)
List pgsql-hackers
Daniel Wood <hexexpert@comcast.net> writes:
> In particular:
>     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.

What we have kicked around a bit is trying to get rid of the additional
snapshot-taking at the start of execution, so that the snapshot taken
at BIND time serves all the way through the query.  That'd require a
fair amount of refactoring I think, but at least it's not a broken idea
on its face.

> In GetSnapshotData because pgxact, is declared volatile, the compiler will not reduce the following two IF tests into
asingle test: 
>     if (pgxact->vacuumFlags & PROC_IN_LOGICAL_DECODING)
>         continue;
>     if (pgxact->vacuumFlags & PROC_IN_VACUUM)
>         continue;

That, on the other hand, is just crummy coding :-(

> I'm still working on quantifying any gain.

It'll be interesting to see if you can show visible improvement from
merging those.  It's enough of a hotspot that I wouldn't be surprised
to find some, but actual numbers would be nice.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Daniel Wood
Date:
Subject: On the need for a snapshot in exec_bind_message()
Next
From: Tom Lane
Date:
Subject: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes