Re: OOM on EXPLAIN with lots of nodes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: OOM on EXPLAIN with lots of nodes
Дата
Msg-id 23580.1421172619@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: OOM on EXPLAIN with lots of nodes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: OOM on EXPLAIN with lots of nodes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 01/13/2015 07:24 PM, Tom Lane wrote:
>> In hindsight, that's a bad API and we should change it to something like
>> ExplainState *es = NewExplainState();
>> so that the sizeof the struct isn't embedded in extension code.  But we
>> definitely can't do that in back branches.

> Actually, it would make sense to do exactly that, to break any 
> extensions that are doing the unsafe thing in an obvious way. The 
> downside would be that an extension using the new API would then not 
> work on an old server.

I guess that's a possibility ...

> We could repurpose one of the existing fields in ExplainState to point 
> to another struct that contains more fields. Something like this:
> ...
> That's pretty ugly, but it would work even if there are ExplainState 
> structs embeded in extensions. As long as they don't try to look at the 
> grouping_stack field; I think that's fairly safe assumption.

Yeah, I was thinking the same thing, but it's *mighty* ugly and would also
create a back-patch hazard, since presumably we'd not do that in HEAD.

> But do we really need to backpatch any of this?

Alexey's example consumes only a couple hundred MB in 9.2, vs about 7GB
peak in 9.3 and up.  That seems like a pretty nasty regression.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [PATCH] explain sortorder
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Check that streaming replica received all data after master shutdown