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
Rod Taylor wrote:
>An 8 k page will hold approx 140 tuples based on your structure. So,
>for every ~100 updates you'll want to run vacuum (regular, not full) on
>the table
Alas, for this application, that means a vacuum once every 5 seconds or
so. I'll see if I can set up a separate little task t
Tom Lane Writes:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
It probably has one visible row in it. If it can changed a lot, there
may be lots of deleted tuples in a row. That would explain why an
index scan speeds things up.
Right, every UPDATE on unique_ids generates a dead row, and a seqscan
h
Tom Lane wrote:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
It probably has one visible row in it. If it can changed a lot, there
may be lots of deleted tuples in a row. That would explain why an
index scan speeds things up.
Right, every UPDATE on unique_ids generates a dead row, and a seq
version: 7.3.2
Ok, not really sure if this a bug per se, but its non-intuitive, and it
goes against the advice stated in the user guide (page 150, "...there is
no plan that can beat sequentially fetching 1 page...")
I have an application that performs many inserts in a second (its doing
real-t
