Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> OK, I think I'm convinced. Here's is the WIP code I put together for the
> blacklist. I'm was looking for a place to put the init call, but since
> it's possibly not going anywhere I stopped :-) . My initial thought
> about substransactions was that we should ignore them for this purpose
> (That's why I used TopTransactionContext for the table).
For the blacklist, I agree we could just ignore subtransactions: all
subtransaction levels are equally uncommitted for this purpose, and
leaving entries from failed subtransactions in place seems like a
non-issue, since they'd never be referenced again. (Well, barring OID
wraparound and an enum-value-OID collision while the transaction runs,
but I think we can ignore that as having probability epsilon.)
But you need to actually put the table in TopTransactionContext, not
CurTransactionContext ;-). Also, I don't think you need an init call
so much as an end-of-transaction cleanup call. Maybe call it
AtEOXactEnum(), for consistency with other functions called in the
same area.
> w.r.t. table size - how large? I confess I haven't seen any systems with
> more than a few hundred enum types. But even a million or two shouldn't
> consume a huge amount of memory, should it?
Dynahash tables are self-expanding, so I don't see a need to stress about
that too much. Anything in 10-100 seems reasonable for initial size.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers