Re: On-Disk Tuple Size
От | Curt Sampson |
---|---|
Тема | Re: On-Disk Tuple Size |
Дата | |
Msg-id | Pine.NEB.4.43.0204201637320.467-100000@angelic.cynic.net обсуждение исходный текст |
Ответы |
Re: On-Disk Tuple Size
|
Список | pgsql-hackers |
[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
В списке pgsql-hackers по дате отправления: