Re: Re: understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr

Поиск
Список
Период
Сортировка
От David Johnston
Тема Re: Re: understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr
Дата
Msg-id CAKFQuwbL4tvXoncC55_3rEqFtqxU9DmRz0VAT3aVH6N+YnoB5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-general



On Wed, Aug 6, 2014 at 10:08 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Tue, Aug 5, 2014 at 4:30 PM, David G Johnston <david.g.johnston@gmail.com> wrote:

Anyway, you should probably experiment with creating a multi-column index
instead of allowing PostgreSQL to BitmapAnd them together.  Likely the
timestamp will have higher cardinality and so should be listed first in the
index.  

No, the timestamp should almost certainly come second because it is used with inequality operators.


​Wouldn't that only matter if a typical inequality was expected to return more rows than a given equality on the other field?  Depending on the cardinality of the ID field I would expect a very large range of dates to be required before digging down into ID becomes more effective.  My instinct say there are relatively few IDs in play but that they are continually adding new rows.

What statistics would the OP have to provide in order to actually make a fact-based determination?

David J​.

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

Предыдущее
От: Ray Stell
Дата:
Сообщение: Re: Questions on dynamic execution and sqlca
Следующее
От: Gregory Taylor
Дата:
Сообщение: Recursive CTE trees + Sorting by votes