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

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: Make the qual cost on index Filter slightly higher than qual coston index Cond.
Дата
Msg-id CAKU4AWqwmHKHMC_466=fBnCUpZRDK-ty4AQsvvmX1q9pNRnNsQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Make the qual cost on index Filter slightly higher than qual coston index Cond.  (Andy Fan <zhihui.fan1213@gmail.com>)
Список pgsql-hackers
Thanks all of you for your feedback. 

On Fri, May 29, 2020 at 9:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tomas Vondra <tomas.vondra@2ndquadrant.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Trouble with hashagg spill I/O pattern and costing
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platforms