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

On Wed, Aug 6, 2014 at 10:08 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Tue, Aug 5, 2014 at 4:30 PM, David G Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)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​.