Re: Should work_mem be stable for a prepared statement? - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Should work_mem be stable for a prepared statement?
Date
Msg-id CAA5RZ0vh2EBp5uwUJZFqAeA4Sgd09d-7zkK8EanXQgjb1Xnsgw@mail.gmail.com
Whole thread Raw
In response to Re: Should work_mem be stable for a prepared statement?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Should work_mem be stable for a prepared statement?
List pgsql-hackers
> It sounds like the behavior change would be desirable or at least
> neutral. I will have to try it out and see if the refactoring is a net
> improvement or turns into a mess.

I think this is a good operational improvement, particularly if
someone wants to change work_mem in a pinch, and the only
option now they have it to somehow get the application to
re-prepare; deallocating all prepared statements or reconnecting.
This is even worse with extended query protocol prepared statements
in which there is no visibility in pg_prepared_statements. So one may
be forced to use DEALLOCATE ALL.

However, I think any GUC that can influence the planner
should be considered for consistency in behavior.
It was mentioned above with the enable_* GUCs, but another
one I can think of is the max_parallel_workers_per_gather which
should then force a re-plan if changed. I have seen users need to turn
that off in a hurry when it impacts their oltp workload.


--
Sami Imseih
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: describe special values in GUC descriptions more consistently
Next
From: Nathan Bossart
Date:
Subject: Re: Statistics Import and Export