Re: Index speeds up one row table (why)?

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Dave E Martin XXIII <postgresql-to(dot)dave(at)dave(dot)to>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Index speeds up one row table (why)?
Date: 2003-06-01 19:04:09
Message-ID: 20030601190409.GA7853@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-performance

On Sun, Jun 01, 2003 at 01:20:03 -0600,
Dave E Martin XXIII <postgresql-to(dot)dave(at)dave(dot)to> wrote:
> 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 to do that (I assume
> at this rate, its better to just keep a connection open, than
> setup/teardown). I don't suppose there is a way to get a trigger to do a
> vacuum (which doesn't want to be in a transaction) (thinking it could
> check for id mod 100=0 or something)? I also assume a few pages isn't
> going to be that bad (just don't let it get to 11000 8).

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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Greg Sabino Mullane 2003-06-02 00:56:42 Detecting proper bison version before make
Previous Message Bruno Wolff III 2003-06-01 18:53:52 Re: Bug or not...

Browse pgsql-performance by date

  From Date Subject
Next Message Ricky Prasla 2003-06-02 01:12:54 Select Query Performance
Previous Message Rod Taylor 2003-06-01 12:14:15 Re: Index speeds up one row table (why)?