Re: surprisingly expensive join planning query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: surprisingly expensive join planning query
Date: 2019-12-02 20:21:47
Message-ID: 10428.1575318107@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On Sun, Dec 01, 2019 at 02:17:15PM -0500, Tom Lane wrote:
>> LGTM.

> Thanks. Do you think this is backpatch-worthy? I'm leaning to yes, but
> maybe tweaking this just in master is fine. The query is somewhat
> artificial and there are probably ways to rewrite it.

I don't object to back-patching.

> The thing that annoys me a bit is that this fix is only partial. It gets
> rid of maybe 80% of the allocations, but there's plenty of unnecessary
> stuff left allocated ...

Meh. I'm not that excited about getting rid of retail space wastage,
unless there are single dominant points such as you found here. For
small stuff it's far better to worry about memory context management.
(Speaking of which, I don't quite see why this would have been a problem
once you got past geqo_threshold; the context resets that GEQO does
should've kept things under control.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-12-02 21:14:58 Re: Using XLogFileNameP in critical section
Previous Message Andrew Dunstan 2019-12-02 19:42:22 Re: Windows buildfarm members vs. new async-notify isolation test