[Moved from general to -hackers.]
On Sat, 20 Apr 2002, Martijn van Oosterhout wrote:
> > In MS SQL server, for example....
>
> Where is the information needed to determine visibility for transactions? In
> Postgres that's at least 16 bytes (cmin,cmax,xmin,xmax). How does SQL server
> do that?
SQL Server doesn't use MVCC; it uses locking. (This is not necessarially
less advanced, IMHO; it has the nice properties of saving a bunch of
space and ensuring that, when transaction isolation is serializable,
commits won't fail due to someone else doing updates. But it has costs,
too, as we all know.)
> > (If there were variable length columns, you would have after this:
> > two bytes for the number of columns, 2 bytes per column for the
> > data offsets within the tuple, and then the variable data.)
>
> In postgres, variable length columns don't cost anything if you don't use
> them.
Right; just as in SQL server. This was just sort of a side note
for those who are curious.
> An int is always 4 bytes, even if there are variable length columns
> elsewhere. The only other overhead is 4 bytes for the OID....
Which would be good to get rid of, if we can.
> ...and 6 bytes for the CTID, which I guess may be unnecessary.
Really? How would things work without it?
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
