From: Richard Neill <rn214@richardneill.org>
To: Sergey Konoplev <gray.ru@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Date: Wed, 19 Dec 2012 23:49:34 +0000
Message-ID: <50D2528E.7000800@richardneill.org> (raw)
In-Reply-To: <CAL_0b1s6_YZDdzt3NizwC8X+dYA37T-4aZOTzw3KJ3-iXuSjjw@mail.gmail.com>
References: <50D22DE2.4090301@richardneill.org>
<CAL_0b1s6_YZDdzt3NizwC8X+dYA37T-4aZOTzw3KJ3-iXuSjjw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 19/12/12 22:59, Sergey Konoplev wrote:
> On Wed, Dec 19, 2012 at 1:13 PM, Richard Neill <rn214@richardneill.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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: rn214@richardneill.org, gray.ru@gmail.com
Subject: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
In-Reply-To: <50D2528E.7000800@richardneill.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox