On Sun, Oct 24, 2010 at 12:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I suppose you could fix this by always updating every row, and storing
>> in each row the total count of elements (or a random number). Then
>> it'd be obvious if you'd read an inconsistent view of the world.
>
> Well, the easy way to read a consistent view of the world is to load the
> cache using an MVCC snapshot instead of SnapshotNow.
Yeah, I have to admit I had never given much thought to how evil
SnapshotNow is. I wonder if we have latent bugs because of this.
Seems like anything where an object is represented by more than one
table row is suspect.
> The current code
> structure isn't amenable to that because it's relying on a syscache to
> fetch the data for it, but that seems pretty inefficient anyway. I'm
> thinking of changing it around so that the enum cache gets loaded with
> a regular systable_beginscan() scan, and then we could load with an
> MVCC snapshot.
That sounds reasonable.
> I'm kind of inclined to go to the float-based representation anyway,
> though, just because not having to update other rows to do an insert
> seems like a good thing. But we could combine that with an MVCC
> snapshot on the read side, which would make renumbering safe, which
> would mean that we could auto-renumber when we ran out of code space
> and not otherwise. Is that getting too complicated?
The complexity doesn't bother me, but I'd probably just renumber every
time. It's worth optimizing enums for speed, but micro-optimizing the
enum DDL for speed may not be worth it, especially because it will
ensure that the renumbering code is very rarely tested.
If you are going to only renumber when necessary, I'd probably make
the ordering position an integer rather than a float, and just set the
values for the initial labels to something like 256 * 10^16, 257 *
10^16, 258 * 10^16, 259 * 10^16; and then some regression tests that
add labels a, z, y, x, .... I dunno if floats have completely
consistent representations on all the platforms we support, but with
integers it should be quite easy to predict the exact point when
you're going to run out of space and what the contents of pg_enum
should be just before and just after that point.
--
Robert Haas
President, Floating-Point Haters Anonymous