Re: Complex filters -> Bad row estimates -> bad query plan

From: Mathieu Fenniak <mathieu(dot)fenniak(at)replicon(dot)com>
To: Michael Lewis <mlewis(at)entrata(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Complex filters -> Bad row estimates -> bad query plan
Date: 2019-08-21 21:18:58
Message-ID: CAHoiPjw4bSVL55NR9vc2amkpV2qa5O4C-n1jAOz8vJNvS6SGEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Michael.

I'll give some join alternatives a shot first... but, that's cool.

What about OFFSET 0 makes this approach work? I'm thinking the OFFSET 0
create an optimization barrier that prevents the planner from collapsing
that sub-query into the top query, and enforces ordering in the query?

I appreciate your thoughts, thank-you very much for the feedback.

Mathieu

On Wed, Aug 21, 2019 at 12:08 PM Michael Lewis <mlewis(at)entrata(dot)com> wrote:

> If those conditions that are throwing off the stats are expected to be
> minimally impactful/filtering few rows, then you can use the one
> tried-and-true optimizer hint (aside from materialized CTEs, stylized
> indexes, etc) --- OFFSET 0 at the end of a sub-query.
>
> SELECT * FROM ( [your existing query without the sub-selects that are
> complicated and produce bad estimates] OFFSET 0 ) WHERE [your other
> conditions that don't produce good estimates]
>
> If there is correlation between field1 and field2, you might also look at
> CREATE STATISTICS assuming you are on PG 10 or 11.
>
> Before I do any of that, I would try LEFT JOIN for Table3 and Table4 then
> use the where conditon "AND 2 = COALESCE( Table3.Status, Table4.Status"
> and see if the optimizer likes that option better.
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2019-08-21 21:25:28 Re: Importing from CSV, auto creating table?
Previous Message stan 2019-08-21 21:15:30 Importing from CSV, auto creating table?