Andrew Dunstan <andrew.duns...@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