RE: proposal: Allocate work_mem From Pool
От | Joseph D Wagner |
---|---|
Тема | RE: proposal: Allocate work_mem From Pool |
Дата | |
Msg-id | 004601d895dd$ed4012e0$c7c038a0$@josephdwagner.info обсуждение исходный текст |
Ответ на | Re: proposal: Allocate work_mem From Pool (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: proposal: Allocate work_mem From Pool
Re: proposal: Allocate work_mem From Pool |
Список | 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.
В списке pgsql-hackers по дате отправления: