Request a Demo
Home   >   mailing lists

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

From Jeff Janes
Subject Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Date
Msg-id CAMkU=1zTU9RtyEAsAAfC5i0r6c-c=i-tVOPfF8J=Q-FgDQ31Qw@mail.gmail.com
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>)
Responses Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?)
List pgsql-performance
Tree view


On Thursday, December 20, 2012, Richard Neill wrote:



- What I'm trying to do is trace the history of the books
  through the system and assign each one a proper unique id.
  So, if I see a book with "parcel_id_code = 37",
  is it a new book (after pid wrap), or is it the same book I saw 1
  minute ago, that hasn't exited the sorter?

I'm not sure how you are implementing this goal, but I don't think it is best done by looping over all books (presumably from some other table?) and issuing an individual query for each one, if that is what you are doing.  Some kind of bulk join would probably be more efficient.

Cheers,

Jeff

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Next
From: Charles Gomes
Date:
Subject: Re: Performance on Bulk Insert to Partitioned Table