From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Andy Fan <zhihui(dot)fan1213(at)gmail(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:04:06 |
Message-ID: | 8810.1590714246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? And the possible
side effects on cases where we do have good data are not to be ignored.
> Anyway, I kinda doubt making the conditions 1.001 more expensive is a
> way to make the planning more robust. I'm pretty sure we could construct
> examples in the opposite direction, in which case this change make it
> more likely we use the wrong index.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-05-29 01:05:06 | Re: segmentation fault using currtid and partitioned tables |
Previous Message | Andres Freund | 2020-05-29 00:55:59 | Re: segmentation fault using currtid and partitioned tables |