Re: Suggestion for optimization - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Suggestion for optimization
Date
Msg-id 200204052110.NAA10222@smtp.ucsd.edu
Whole thread Raw
In response to Re: Suggestion for optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> >> It would be nice if total table cardinality could be maintained live.
> >
> > How would this work with MVCC?
>
> It wouldn't.  That's why it's not there.  Under MVCC, table cardinality
> is in the eye of the beholder...

That makes me curious how oracle implements it. I was under the impression 
that oracle managed to get the two together (MVCC and cardinality).

Also, can't triggers basically solve the problem from a functionaility 
standpoint? I mean, it would be slow for inserts, but I wonder if similar 
principles could be applied without the full overhead of triggers?

What I had in mind was to create a stats table (I guess much like the one 
that already exists, or a separate attribute of the existing one) and all of 
the tables in there, with a rowcount. Once a row is inserted, the trigger 
runs and updates the count (or decrements for delete), making the new count 
visible to the current transaction. Then when the transaction commits, it's 
visible everywhere at the same time as the count. 

Is there anything wrong with that setup, other than the obvious performance 
hit?

By the way, since this discussion has happened before, I actually read a 
similar idea in a previous email (if I remember correctly), but I didn't see 
much talk about it.

Regards,Jeff


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: Suggestion for optimization
Next
From: Joe Conway
Date:
Subject: Re: PQescapeBytea is not multibyte aware