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

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