Re: Random Page Cost and Planner

Поиск
Список
Период
Сортировка
От David Jarvis
Тема Re: Random Page Cost and Planner
Дата
Msg-id AANLkTinAhrwwwQKh6NrX-nnvcpxT1EFFlZrUxhaDB87C@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Random Page Cost and Planner  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Ответы Re: Random Page Cost and Planner  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Список pgsql-performance
Salut, Cédric.

I wonder what the plan will be if you replace sc.taken_* in :
m.taken BETWEEN sc.taken_start AND sc.taken_end
by values. It might help the planner...

That is a fairly important restriction. I will try making it (year1||'-01-01')::date, but I have no constant value for it -- it is a user-supplied parameter. And then there's the year wrapping problem, too, where the ending year will differ from the starting year in certain cases. (Like querying rows between Dec 22, 1900 to Mar 22 1901 rather than Mar 22 1900 to Dec 22 1900. The first query is the winter season and the second query is all seasons except winter.)
 
Also, I'll consider explicit ordered join but I admit I haven't read
the whole thread (in particular the table size).

C'est une grosse table. Pres que 40 million lines; il y a sept tableau comme ca.

I tried an explicit join in the past: it did not help much. But that was before everything was running this fast, so now that the system performs differently, maybe it will help?

Dave

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

Предыдущее
От: Konrad Garus
Дата:
Сообщение: Re: shared_buffers advice
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Query timing increased from 3s to 55s when used as function instead of select