On Sat, Apr 20, 2002 at 01:55:38PM +0900, Curt Sampson wrote:
> > AFAIK, all databases have nontrivial per-row overheads; PG might be
> > a bit worse than average, but this is a significant issue no matter
> > which DB you use.
>
> For certain types of tables, such the sort of table joining two
> others for which I forget the proper term:
>
> CREATE TABLE folder_contents (
> folder_id int NOT NULL,
> item_id int NOT NULL,
> PRIMARY KEY (folder_id, item_id))
>
> some databases are much better. In MS SQL server, for example, since
> there are no variable length columns, the tuple format will be:
>
> 1 byte status bits A
> 1 byte status bits B
> 2 bytes fixed-length columns data length
> 4 bytes DATA: folder_id
> 4 bytes DATA: item_id
> 2 bytes number of columns
> 1 byte null bitmap (unfortunately doesn't go away in SQL
> server even when there are no nullable columns)
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?
> (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. An int is always 4 bytes, even if there are variable length columns
elsewhere. The only other overhead is 4 bytes for the OID and 6 bytes for
the CTID, which I guess may be unnecessary.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Canada, Mexico, and Australia form the Axis of Nations That
> Are Actually Quite Nice But Secretly Have Nasty Thoughts About America
