Re: Re: understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr - Mailing list pgsql-general

From David Johnston
Subject Re: Re: understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr
Date
Msg-id CAKFQuwbL4tvXoncC55_3rEqFtqxU9DmRz0VAT3aVH6N+YnoB5w@mail.gmail.com
Whole thread Raw
In response to Re: Re: understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr  (Jeff Janes <jeff.janes@gmail.com>)
List 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 by date:

Previous
From: Ray Stell
Date:
Subject: Re: Questions on dynamic execution and sqlca
Next
From: Gregory Taylor
Date:
Subject: Recursive CTE trees + Sorting by votes