Re: Why does the query planner use two full indexes, when a dedicated partial index exists?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Дата
Msg-id CAMkU=1zTU9RtyEAsAAfC5i0r6c-c=i-tVOPfF8J=Q-FgDQ31Qw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why does the query planner use two full indexes, when a dedicated partial index exists?  (Richard Neill <rn214@richardneill.org>)
Ответы Re: Why does the query planner use two full indexes, when a dedicated partial index exists?  (Richard Neill <rn214@richardneill.org>)
Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?)  (Richard Neill <rn214@richardneill.org>)
Список pgsql-performance


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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Следующее
От: Charles Gomes
Дата:
Сообщение: Re: Performance on Bulk Insert to Partitioned Table