Re: [HACKERS] Runtime Partition Pruning
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Runtime Partition Pruning |
Дата | |
Msg-id | CA+TgmoYy_FXqGd2WCckF7OZG3Y0MfsA_q6RRjmv36wgDqcLx-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Runtime Partition Pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Runtime Partition Pruning
|
Список | pgsql-hackers |
On Thu, Apr 12, 2018 at 6:01 PM, David Rowley <david.rowley@2ndquadrant.com> wrote: > On 13 April 2018 at 04:57, Robert Haas <robertmhaas@gmail.com> wrote: >> BTW, looking at ExecSetupPartitionPruneState: >> >> /* >> * Create a sub memory context which we'll use when making calls to the >> * query planner's function to determine which partitions will >> match. The >> * planner is not too careful about freeing memory, so we'll ensure we >> * call the function in this context to avoid any memory leaking in the >> * executor's memory context. >> */ >> >> This is a sloppy cut-and-paste job, not only because somebody changed >> one copy of the word "planner" to "executor" and left the others >> untouched, but also because the rationale isn't really correct for the >> executor anyway, which has memory contexts all over the place and >> frees them all the time. I don't know whether the context is not >> needed at all or whether the context is needed but the rationale is >> different, but I don't buy that explanation. > > The comment is written exactly as intended. Unsure which of the > "planner"s you think should be "executor". > > The context is needed. I can easily produce an OOM without it. Oh, crap. You know, I totally misread what that comment was trying to say. Sorry. But I wonder why it's the executor's job to clean up after the planner, instead of adjusting the relevant planner functions to avoid leaking memory? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: