From: John A Meinel <john@arbash-meinel.com>
To: Merlin Moncure <merlin.moncure@rcsonline.com>
Cc: Bruno Wolff III <bruno@wolff.to>
Cc: Postgresql Performance <pgsql-performance@postgresql.org>
Cc: elein <elein@varlena.com>
Subject: Re: tricky query
Date: Tue, 28 Jun 2005 14:42:21 -0500
Message-ID: <42C1A81D.1060507@arbash-meinel.com> (raw)
In-Reply-To: <6EE64EF3AB31D5448D0007DD34EEB3415C2C07@Herge.rcsinc.local>
References: <6EE64EF3AB31D5448D0007DD34EEB3415C2C07@Herge.rcsinc.local>
Merlin Moncure wrote:
>>On Tue, Jun 28, 2005 at 12:02:09 -0400,
>> Merlin Moncure <merlin.moncure@rcsonline.com> wrote:
>>
>>
>>>Confirmed. Hats off to you, the above some really wicked querying.
>>>IIRC I posted the same question several months ago with no response
>>>
>>>
>and
>
>
>>>had given up on it. I think your solution (smallest X1 not in X) is
>>>
>>>
>a
>
>
>>>good candidate for general bits, so I'm passing this to varlena for
>>>review :)
>>>
>>>SELECT t1.id+1 as id_new FROM id_test t1
>>> WHERE NOT EXISTS
>>> (SELECT t2.id FROM id_test t2 WHERE t2.id = t1.id+1)
>>> ORDER BY t1.id LIMIT 1;
>>>
>>>
>>You need to rework this to check to see if row '1' is missing. The
>>above returns the start of the first gap after the first row that
>>isn't missing.
>>
>>
>
>Correct.
>
>In fact, I left out a detail in my original request in that I had a
>starting value (easily supplied with where clause)...so what I was
>really looking for was a query which started at a supplied value and
>looped forwards looking for an empty slot. John's supplied query is a
>drop in replacement for a plpgsql routine which does exactly this.
>
>The main problem with the generate_series approach is that there is no
>convenient way to determine a supplied upper bound. Also, in some
>corner cases of my problem domain the performance was not good.
>
>Merlin
>
>
Actually, if you already have a lower bound, then you can change it to:
SELECT t1.id+1 as id_new FROM id_test t1
WHERE t1.id > id_min
AND NOT EXISTS
(SELECT t2.id FROM id_test t2 WHERE t2.id = t1.id+1)
ORDER BY t1.id LIMIT 1;
This would actually really help performance if you have a large table
and then empty entries start late.
On my system, where the first entry is 64k, doing where id > 60000
speeds it up back to 80ms instead of 1000ms.
John
=:->
Attachments:
signature.asc (application/pgp-signature, 252B) download
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: john@arbash-meinel.com, merlin.moncure@rcsonline.com, bruno@wolff.to, elein@varlena.com
Subject: Re: tricky query
In-Reply-To: <42C1A81D.1060507@arbash-meinel.com>
* 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