From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Non-transactional pg_class, try 2 |
Date: | 2006-06-26 21:36:14 |
Message-ID: | 20060626213614.GF11926@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > What I'm after is not freezing for read-only media, nor archive, nor
> > read-only tables. What I'm after is removing the requirement that all
> > databases must be vacuumed wholly every 2 billion transactions.
>
> Well, if that's the only goal then I hardly think we need to have a
> discussion, because your alternative #1 is *obviously* the winner:
>
> > 1. Remove the special case, i.e., process frozen databases in VACUUM
> > like every other database.
> > This is the easiest, because no extra logic is needed. Just make
> > sure they are vacuumed in time. The only problem would be that we'd
> > need to uselessly vacuum tables that we know are frozen, from time to
> > time. But then, those tables are probably small, so what's the
> > problem with that?
I'm happy to do at least this for 8.2. We can still try to do the
non-transactional catalog later, either in this release or the next; the
code is almost there, and it'll be easier to discuss/design because
we'll have taken the relminxid stuff out of the way.
So if everyone agrees, I'll do this now. Beware -- this may make you
vacuum databases that you previously weren't vacuuming. (I really doubt
anyone is setting datallowconn=false just to skip vacuuming big
databases, but there are people with strange ideas out there.)
> So if you want to bring in the other goals that you're trying to pretend
> aren't there, step right up and do it. You have not here made a case
> that would convince anyone that we shouldn't just do #1 and be done with
> it.
We can do it in a separate discussion.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-06-26 21:36:38 | Re: [HACKERS] Overhead for stats_command_string et al, take |
Previous Message | Tom Lane | 2006-06-26 21:31:53 | Re: [HACKERS] Overhead for stats_command_string et al, take 2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-06-26 21:36:38 | Re: [HACKERS] Overhead for stats_command_string et al, take |
Previous Message | Tom Lane | 2006-06-26 21:31:53 | Re: [HACKERS] Overhead for stats_command_string et al, take 2 |