Re: Fwd: Proposal - UUID data type - Mailing list pgsql-hackers

First - please stop copying this list - this is not the "convince Jerry to include UUID in MySQL" mailing list.<br
/><br/> Really - I don't care what he thinks. But, on the subjects themselves and how they apply to *PostgreSQL*:<br
/><br/><blockquote cite="mid:f1048bd4-52bf-428b-af62-71fba0c645fa@t54g2000hsg.googlegroups.com" type="cite"><pre
wrap="">
Non-standard features just force people to stick with that one
product. In the long run, the only people who benefit are the product
developers. </pre></blockquote><br /> I chose PostgreSQL over MySQL because it provided numerous features - both
standardand non - that I needed on the day I made my decision. I don't care about the long run as a user. One might as
wellsay 90% of the world is wrong for using Microsoft products, because it locks one into Microsoft. One can say this -
andpeople do say this - but none of this changes the fact that 90% of the world is relatively happy with their choice.
Theyvoted with their dollars. All decisions should be made on a cost-benefit analysis - they should not be based on
somearbitrary code like "I will not choose a solution that locks me in".<br /><br /> Additionally - in the context of
MySQL- the main reason I chose PostgreSQL over MySQL is because it provided things like CREATE VIEW, which MySQL did
notat the time. People such as Jerry can pretend that standards guarantee that a feature is in all products, but it
seemsquite clear that just because something is a standard does NOT mean it is implemented the same everywhere, or even
atall. At the time I chose PostgreSQL it was my opinion that PostgreSQL was far more standards-compliant than MySQL was
goingto be for at least a few years. I am glad I came to the correct conclusion. MySQL implemented ACID as an
after-thought.I mean - comone.<br /><br /><blockquote
cite="mid:f1048bd4-52bf-428b-af62-71fba0c645fa@t54g2000hsg.googlegroups.com"type="cite"><blockquote type="cite"><pre
wrap="">Thisis incorrect. UUID at 16 bytes is already "long" in terms of
 
being
used as a primary index. In an 8K page, one can only fit 512 UUIDs
(forgetting the requirement for headers) - if it was stored as 32
bytes
- or 36 bytes, or 40 bytes (with punctuation), it would be at less
than
256 UUIDs per page. For a join table joining one set of UUID to
another
set, that's < 256 vs < 128. Doubling the size of an index row roughly
doubles the time to look up the value.   </pre></blockquote><pre wrap="">
Incorrect.  Doubling the size of the index has very little effect on
how
long it takes to look up a value.  Intelligent databases use a binary
search so doubling the size only means one additional comparison need
be
done.  And heavily used indexes are generally cached in memory anyway. </pre></blockquote><br /> Wrong. A binary search
thatmust read double the number of pages, and compare double the number of bytes, will take double the amount of time.
Thereare factors that will reduce this, such as if you assume that most of the pages are in memory or cache memory,
thereforethe time to read the page is zero, therefore it's only the time to compare bytes - but at this point, the
majorityof the time is spent comparing bytes, and it's still wrong. If we add in accounting for the fact that UUID is
comparedusing a possibly inlined memcpy() compared to treating it as a string where it is variable sized, and much
harderto inline (double the number of oeprations), and it's pretty clear that the person who would make such a
statementas above is wrong.<br /><br /> As another poster wrote - why not double the size of all other data structures
too.It costs nothing, right?<br /><br /> Why does MySQL have a 3-byte integer support if they truly believe that saving
1byte in 4 doesn't result in a savings for keys?<br /><br /> Cheers,<br /> mark<br /><br /><pre class="moz-signature"
cols="72">--
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>