Message-ID: <50D2528E.7000800@richardneill.org>
Date: Wed, 19 Dec 2012 23:49:34 +0000
From: Richard Neill <rn214@richardneill.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
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?
References: <50D22DE2.4090301@richardneill.org>
	<CAL_0b1s6_YZDdzt3NizwC8X+dYA37T-4aZOTzw3KJ3-iXuSjjw@mail.gmail.com>
In-Reply-To: 
 <CAL_0b1s6_YZDdzt3NizwC8X+dYA37T-4aZOTzw3KJ3-iXuSjjw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


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