Re: Analyze results in more expensive query plan

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Jeremy Altavilla <jeremyaltavilla(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Analyze results in more expensive query plan
Date: 2019-05-21 02:04:43
Message-ID: CAKJS1f91kNcgW0HTPJhtWEkW-hbncJpqdpAU6gmcZ=Bx15yR6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 21 May 2019 at 08:23, Jeremy Altavilla
<jeremyaltavilla(at)gmail(dot)com> wrote:
>
> Thanks for the suggestion. I created extended statistics objects for the two tables in question. Unfortunately the resulting plan was the same (and had the same estimates). It looks like the extended stats discovered a potentially useful correlation on bag: "2, 3 => 1" (owner_id, bag_type_id => id). I'm guessing this wasn't usable because the docs state "They are not used to improve estimates for equality conditions comparing two columns".

I'd say that since the time spent planning is near 3x what is spent
during execution that you're wasting your time trying to speed up the
execution. What you should be thinking about is using PREPAREd
statements to avoid the planning overhead completely. If that's not
possible then you've more chance of reducing the time spent planning
by reducing the statistics on the table rather than adding more
planning overhead by adding extended stats. You might want to
experiment with ALTER TABLE ... ALTER COLUMN ... SET STATISTICS ..;
and setting those down a bit then analyzing the tables again.
Although, that's likely only going to make a very small difference, if
any, than getting rid of the planning completely.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Walter Smith 2019-05-21 02:04:44 Re: Temporarily very slow planning time after a big delete
Previous Message Tom Lane 2019-05-21 01:04:58 Re: Temporarily very slow planning time after a big delete