Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

From: Yuto Hayamizu <y(dot)hayamizu(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation
Date: 2018-01-16 09:45:22
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Sun, Jan 7, 2018 at 8:25 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Greetings,
> * Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> > On Thu, Nov 9, 2017 at 12:33 PM, Ashutosh Bapat
> > <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> > > Looking at order_qual_clauses(), we can say that a set of quals q1
> > > .... qn are ordered the same irrespective of the set of clauses they
> > > are subset of. E.g. if {q1 .. qn} is subset of Q (ordered as Qo) and
> > > also Q' (ordered as Q'o) the order in which they appear in Qo and Q'o
> > > is same. So, even if different paths segregate the clauses in
> > > different set, within each set the order is same. FWIW, we can order
> > > all clauses in largest set once and use that order every time. Albeit
> > > we will have to remember the order somewhere OR make the separator
> > > routine retain the order in the larger set, which I guess is true
> > > about all separator functions.
> >
> > I am not sure what to think about this patch, so moved to next CF. The
> > patch still applies. Hayamizu-san, it would be nice as well if you
> > could review other's patches. One patch reviewed for one patch
> > submitted, with equal difficulty. You should also get a community
> > account so as it is possible to add your name as an author of this
> > patch.
> While this patch does still apply, it doesn't pass the 'make check'
> regression tests and there appears to be concern raised up-thread about
> the performance impact.
> Yuto Hayamizu, it looks like some good questions were raised and which
> need to be addressed, in addition to making sure that the patch at least
> passes 'make check', so I'm leaving this as waiting-for-author. If you
> believe the patch is no longer viable, we can change it to 'returned
> with feedback', otherwise, an updated patch and some responses to the
> questions raised would be great as we're already a week into this
> commitfest and this thread has been dormant since near the start of the
> last CF.
> Thanks!
> Stephen

Thank you for your kind guidance, and sorry for late reply.

Attached patch fixes regression tests and now it passes the 'make check' tests.
Since this patch changes cost estimation in set_baserel_size_estimates,
picked query plans were changed for some tests, so I've updated their
expected EXPLAIN results.

I'm going to answer raised questions by replying to each message soon.


Yuto Hayamizu

Attachment Content-Type Size
Mitigate-filter-cost-overestimation-v2.patch application/octet-stream 10.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-01-16 10:13:41 TOAST table created for partitioned tables
Previous Message Prabhat Sahu 2018-01-16 09:17:32 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)