Re: Why does the query planner use two full indexes, when a dedicated partial index exists? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Date
Msg-id 11997.1356018206@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why does the query planner use two full indexes, when a dedicated partial index exists?  (Richard Neill <rn214@richardneill.org>)
List pgsql-performance
Richard Neill <rn214@richardneill.org> writes:
> Also, I wonder whether it matters which order the indexes are created in?

IIRC, if the estimated costs of using two different indexes come out the
same (to within 1% or so), then the planner keeps the first-generated
path, which will result in preferring the index with smaller OID.  This
effect doesn't apply to your problem query though, since we can see from
the drop-experiments that the estimated costs are quite a bit different.

A more likely explanation if you see some effect that looks like order
dependency is that the more recently created index has accumulated less
bloat, and thus has a perfectly justifiable cost advantage.

            regards, tom lane


pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: hash join vs nested loop join
Next
From: Tom Lane
Date:
Subject: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?