Re: [PATCHES] Non-transactional pg_class, try 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Non-transactional pg_class, try 2
Date: 2006-06-26 21:26:33
Message-ID: 23140.1151357193@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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?

> 2. Mark frozen databases specially somehow.
> To mark databases frozen, we need a way to mark tables as frozen.
> How do we do that? As I explain below, this allows some nice
> optimizations, but it's a very tiny can full of a huge amount of
> worms.

Avoiding a vacuum pass over template0 once every 2 billion transactions
cannot be thought worthy of the amount of complexity and risk entailed
in the nontransactional-catalog thing. Especially since in the normal
case those would be read-only passes (the tuples all being frozen already).

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-26 21:31:53 Re: [HACKERS] Overhead for stats_command_string et al, take 2
Previous Message Bruce Momjian 2006-06-26 21:26:03 Re: [HACKERS] Overhead for stats_command_string et al, take 2

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-06-26 21:31:53 Re: [HACKERS] Overhead for stats_command_string et al, take 2
Previous Message Bruce Momjian 2006-06-26 21:26:03 Re: [HACKERS] Overhead for stats_command_string et al, take 2