RE: proposal: Allocate work_mem From Pool

From: "Joseph D Wagner" <joe(at)josephdwagner(dot)info>
To: "'Justin Pryzby'" <pryzby(at)telsasoft(dot)com>
Cc: <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: proposal: Allocate work_mem From Pool
Date: 2022-07-12 10:55:39
Message-ID: 004601d895dd$ed4012e0$c7c038a0$@josephdwagner.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> I think it would be better if work_mem was allocated from a pool
>> of memory

> I think this has been proposed before, and the issue/objection
> with this idea is probably that query plans will be inconsistent,
> and end up being sub-optimal.

> work_mem is considered at planning time, but I think you only
> consider its application execution. A query that was planned
> with the configured work_mem but can't obtain the expected
> amount at execution time might perform poorly. Maybe it
> should be replanned with lower work_mem, but that would
> lose the arms-length relationship between the planner-executor.

> Should an expensive query wait a bit to try to get more
> work_mem? What do you do if 3 expensive queries are all
> waiting ?

Before I try to answer that, I need to know how the scheduler works.

Let's say there's a max of 8 worker process, and 12 queries trying to run.
When does query #9 run? After the first of 1-8 completes, simple FIFO?
Or something else?

Also, how long goes a query hold a worker process? All the way to
completion? Or does is perform some unit of work and rotate to
another query?

Joseph D Wagner

P.S. If there's a link to all this somewhere, please let me know.
Parsing through years of email archives is not always user friendly or
helpful.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-07-12 10:58:48 Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Previous Message Alexander Korotkov 2022-07-12 10:29:44 Re: POC: Lock updated tuples in tuple_update() and tuple_delete()