From: | Richard Neill <rn214(at)richardneill(dot)org> |
---|---|
To: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Why does the query planner use two full indexes, when a dedicated partial index exists? |
Date: | 2012-12-19 23:49:34 |
Message-ID: | 50D2528E.7000800@richardneill.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 19/12/12 22:59, Sergey Konoplev wrote:
> On Wed, Dec 19, 2012 at 1:13 PM, Richard Neill <rn214(at)richardneill(dot)org> wrote:
>> Index Scan using tbl_tracker_performance_1_idx on tbl_tracker
>> (cost=0.00..5440.83 rows=1 width=174) (actual time=0.052..0.052 rows=0
>> loops=1)
>> Index Cond: (parcel_id_code = 53030)
>
> It looks like your index is bloated. Have you had a lot of
> updates/deletes on rows with exit_state is null?
>
> Try to reindex tbl_tracker_performance_1_idx.
>
> To reindex it without locks create a new index with temporary name
> concurrently, delete the old one and rename the new one using the old
> name.
>
Hi Sergey,
Thanks for your suggestion. Yes, I can see what you mean: over the 3
weeks during which we deployed the system, every single row has at one
point had the exit_state as null, before being updated.
Essentially, as time moves on, new rows are added, initially with
exit_state null, then a few minutes later we update them to exit_state
1, then a few weeks later, they are removed.
[Explanation: the system tracks books around a physical sortation
machine; the sorter uses a "parcel_id_code" which (for some really daft
reason suffers wraparound at 99999, i.e. about every 3 hours), books
whose exit_state is null are those which are still on the sortation
machine; once they exit, the state is either 1 (successful delivery) or
2 (collision, and down the dump chute).]
BUT....
* The reindex solution doesn't work. I just tried it, and the query
planner is still using the wrong indexes.
* If the tbl_tracker_performance_1_idx had indeed become bloated,
wouldn't that have meant that when the query planner was forced to use
it (by deleting the alternative indexes), it would have been slow?
Also, I thought that reindex wasn't supposed to be needed in normal
operation.
Best wishes,
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Konoplev | 2012-12-20 00:08:58 | Re: Why does the query planner use two full indexes, when a dedicated partial index exists? |
Previous Message | Sergey Konoplev | 2012-12-19 22:59:39 | Re: Why does the query planner use two full indexes, when a dedicated partial index exists? |