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

On Mon, 2006-06-12 at 19:15 -0400, Tom Lane wrote:
> [ moving to -hackers to get some more eyeballs on the question ]
>
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Sun, 2006-06-11 at 17:53 -0400, Alvaro Herrera wrote:
> >> Here I repost the patch to implement non-transactional catalogs, the
> >> first of which is pg_ntclass, intended to hold the non-transactional
> >> info about pg_class (reltuples, relpages).
>
> > Will a user be able to update reltuples and relpages manually?
>
> No, which is a tad annoying now that you mention it. I'm not sure that
> there's any very good reason for users to want to do that, though. Once
> or twice I've hacked those fields manually to set up test cases for the
> planner, which is why I'd be annoyed to lose the ability --- but does it
> really matter to users? (Especially in view of the fact that the
> planner no longer trusts relpages anyway.)

No need to have an SQL route. A special function call would suffice.

I'd like to be able to set up a test database that has the statistics
copied from the live system. A schema only pg_dump with mods is all I
need, but it sounds like we're moving away from that. We can then
perform various what-ifs on the design.

Elsewhere, it has been discussed that we might hold the number of blocks
in a relation in shared memory. Does that idea now fall down, or is it
complementary to this? i.e. would we replace ANALYZE's relpages with an
accurate relpages for the planner?

> It does seem like rather a lot of mechanism and overhead though,
> especially in view of Alvaro's worries about the non-cacheability of
> pg_class_nt rows. I wonder whether we shouldn't take two steps back
> and rethink.

Review, yes. Could still be the best way.

> The main thing we are trying to accomplish here is to decouple
> transactional and nontransactional updates to a pg_class row.

With the goal being avoiding table bloat??

> Is there another way to do that? Do we need complete decoupling?

> It strikes me that the only case where we absolutely must not lose a
> nontransactional update is where we are un-freezing a frozen rel.

Not sure why you'd want to do that, assuming I've understood you.

For me, freezing is last step before writing to WORM media, so there is
never an unfreeze step.

> If we could guarantee that un-freezing happens before any transactional
> update within a particular transaction, then maybe we could have that.
> Manual updates to pg_class seem like they'd risk breaking such a
> guarantee, but maybe there's a way around that. Personally I'd be
> willing to live with commands that try to modify a frozen rel erroring
> out if they see the current pg_class row is uncommitted.

Sounds OK. It's a major state change after all.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com