Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.
Date: 2020-05-29 01:20:37
Message-ID: CAKU4AWqwmHKHMC_466=fBnCUpZRDK-ty4AQsvvmX1q9pNRnNsQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks all of you for your feedback.

On Fri, May 29, 2020 at 9:04 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> > On Wed, May 27, 2020 at 09:58:04PM +0800, Andy Fan wrote:
> >> so we need to optimize the cost model for such case, the method is the
> >> patch I mentioned above.
>
> > Making the planner more robust w.r.t. to estimation errors is nice, but
> > I wouldn't go as far saying we should optimize for such cases.
>
> Yeah, it's a serious mistake to try to "optimize" for cases where we have
> no data or wrong data. By definition, we don't know what we're doing,
> so who's to say whether we've made it better or worse?

Actually I think it is a more robust way.. the patch can't fix think all
the impact
of bad statistics(That is impossible I think), but it will make some
simple things
better and make others no worse. By definition I think I know what we are
doing
here, like what I replied to Tomas above. But it is possible my think is
wrong.

> The other serious error we could be making here is to change things on
> the basis of just a few examples. You really need a pretty wide range
> of test cases to be sure that you're not making things worse, any time
> you're twiddling basic parameters like these.
>
>
I will try more thing with this direction, thanks for suggestion.

--
Best Regards
Andy Fan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-05-29 01:46:17 Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platforms
Previous Message Jeff Davis 2020-05-29 01:14:55 Re: Trouble with hashagg spill I/O pattern and costing