Re: Index speeds up one row table (why)? - Mailing list pgsql-bugs

From Dave E Martin XXIII
Subject Re: Index speeds up one row table (why)?
Date
Msg-id 3EDAF956.9010307@dave.to
Whole thread Raw
In response to Re: Index speeds up one row table (why)?  (Dave E Martin XXIII <postgresql-to.dave@dave.to>)
Responses Re: Index speeds up one row table (why)?  (Peter Childs <blue.dragon@blueyonder.co.uk>)
List pgsql-bugs
Bruno Wolff III wrote:

>Maybe you should reconsider how badly you want the app to be totally database
>agnostic? Using a sequence might be less of a contortion than using vacuum
>a few times a minute. You are likely to have similar performance issues
>with other databases, so this section of code may not turn out to be very
>portable in any case.
>
>
Maybe I can further abstract out the generate unique-id portion, Since
unique-id generation does seem to be a pretty common database extension
(for some reason...), and then provide a generic schema definition, and
a postgresql specific one (along with whatever others I can drum up).
The generic one will rely on the software to come up with the unique id
in the fashion I'm currently doing.

Speaking of which, is there a better way than what i'm currently doing
(when the database doesn't have any such support)? I've heard of one
method based on something like "select max(id)+1 from table" but this
seems error prone, at the very least, you'd have to have a unique index,
and be prepared to redo on failure, which could get messy if its a big
transaction, and frequent if there is a lot of concurrent inserting
going on.

pgsql-bugs by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Detecting proper bison version before make
Next
From: Peter Childs
Date:
Subject: Re: Index speeds up one row table (why)?