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?
Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?) |
| Список | 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 по дате отправления: