Re: Should work_mem be stable for a prepared statement?

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should work_mem be stable for a prepared statement?
Date: 2025-02-28 22:54:36
Message-ID: CAA5RZ0vCnPZseUD4moLEDZkhYaUf9PDwY6fxLGtq=hEEsEEryA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The argument for treating work_mem specially is that it has effects at
> both plan time and run time, so that the planner's cost assumptions
> are invalidated if the executor uses a different value than the
> planner did.

I see that now. Thanks!

> Maybe that refactoring is one that would conveniently apply to
> other GUCs, or maybe it isn't. I'm content to await details
> before arguing about what we "should" do.

Agree.

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2025-02-28 23:05:10 Re: [18] CREATE SUBSCRIPTION ... SERVER
Previous Message Melanie Plageman 2025-02-28 22:52:35 Re: Log connection establishment timings