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
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 |