Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior
Date
Msg-id CAPmGK14Lo3XCS8osU77WNTQwyz7Y=A-cXmf7Ns09=FUnXJcCmg@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior  (Andy Fan <zhihuifan1213@163.com>)
List pgsql-hackers
On Fri, Dec 6, 2024 at 7:50 PM Andy Fan <zhihuifan1213@163.com> wrote:
> Apart from the above issue, what do you think about that we are using a
> 'SELECT pg_catalog.pg_refresh_snapshot()' to let the remote do the
> refresh_snapshot VS 'a new message type for this'?  There are lots of
> things happen in the 'SELECT' way like 'a extra network communication',
> 'a complete parser-planner-executor workflow.' With a new message type
> for this, we can send the message character with the next query
> together. if so, can the two overheads removed?

I think it might be a good idea to extend simple/extend query
protocols that way, but even if so, I would like to leave that for
future work, because even without that, I think this is still an
improvement, and I do not want to set the goal for the first cut too
high.

Having said that, if the next query uses simple query protocol, we can
avoid the extra communication by sending the two queries in a single
function call.  I will do that in the next version.

Thanks for the comment!

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior
Next
From: Kirill Reshke
Date:
Subject: Re: clean up create|alter domain stmt incompatiable constraint error case and add regression test