From: | Andrew Snow <als(at)giskard(dot)fl(dot)net(dot)au> |
---|---|
To: | Thomas <englim(at)pc(dot)jaring(dot)my> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgresqlism & Vacuum? |
Date: | 2000-04-14 05:44:38 |
Message-ID: | Pine.BSF.4.21.0004141535500.51509-100000@giskard.fl.net.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 14 Apr 2000, Thomas wrote:
> For large 24x7 installations, it's impossible to vacuum nightly because when
> postgresql is vacuuming the table is locked up, to the end-user the database
> has already hung.
That's right. I complained about this in a discussion with a Postgresql
developer, who assured me they were working towards a fix. I really don't
care whether the vacuuming is fixed so that it does not lock the table
completely, or that vacuuming becomes say, a once-a-month or less frequent
operation. For some reason everyone who is used to working with PostgreSQL
accepts the fact that you have to vacuum nightly - to outsiders it seems
like a major flaw with the system.
> There has been effort to speed up the vacuuming process, but this isn't the
> cure. I believe the fault lies on the optimizer.
Sure, the vacuum process speed is fine for small tables, but what about the
big ones where the table gets locked for 5 minutes? What a joke!
> Why save on micro-seconds to use sequential scan when the table is small and
> later 'forgets' that the table is now big because you didn't vacuum analyze?
> Why can't the optimizer just use indexes when they are there and not
> 'optimize' for special cases when the table is small to save micro-seconds?
Well its more than microseconds I presume, as opening indexes involves
opening files, which takes milliseconds rather than microseconds.
Andrew.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Snow | 2000-04-14 05:45:03 | Re: Postgresqlism & Vacuum? |
Previous Message | Thomas | 2000-04-14 05:13:12 | Postgresqlism & Vacuum? |