From: | Jeff Davis <list-pgsql-hackers(at)dynworks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Suggestion for optimization |
Date: | 2002-04-05 21:09:08 |
Message-ID: | 200204052110.NAA10222@smtp.ucsd.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-04-05 21:53:47 | Re: PQescapeBytea is not multibyte aware |
Previous Message | Dann Corbit | 2002-04-05 21:07:51 | Re: Suggestion for optimization |