Hi,
On August 24, 2019 12:41:03 PM PDT, Tom Lane wrote:
>Jeff Janes writes:
>> Most of the time is not after the clock stops, but before the
>stepwise
>> ANALYZE clock starts. If you just do an EXPLAIN rather than EXPLAIN
>> ANALYZE, that is also slow. The giant hash table is created during
>t
Jeff Janes writes:
> Most of the time is not after the clock stops, but before the stepwise
> ANALYZE clock starts. If you just do an EXPLAIN rather than EXPLAIN
> ANALYZE, that is also slow. The giant hash table is created during the
> planning step (or somewhere around there
It's in executor
On Thu, Aug 22, 2019 at 1:09 AM Pavel Stehule
wrote:
> čt 22. 8. 2019 v 3:11 odesílatel Jeff Janes napsal:
>
>> ...
> But the same advance in v12 which makes it harder to fool with your test
>> case also opens the possibility of fixing your real case.
>>
>
> I think so much more interesting sh
Thanks Tom, yes I'd say it's using a lot of memory, but wouldn't call it
"leak" as it doesn't grow during the 30 min or so that this query runs.
It explodes to 4GB and then stays flat until done.
Yes, and this time the query is super complicated with many joins and
tables involved. The query p
