Re: Tuple data

From: "Michael Richards" <miker(at)interchange(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Hannu Krosing" <hannu(at)tm(dot)ee>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tuple data
Date: 2000-12-18 02:22:32
Message-ID: 05fb01c06899$60f7a020$0200a8c0@digitallis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This is what I assumed the problem to be but I wasn't sure if there would be
more to it or not.

My question now is: Should the order in which columns are physically stored
matter?

Since the details of where to find the columns in the tuple data are stored
in pg_attribute, I'd think this is a place where the storage layer should be
free to store it as it likes. Consider as a performance enhancement
shuffling all the variable length columns to the end of the table. This
would save having to look at the size of all the variable length columns in
order to examine a fixed length column.

Obviously since I only have a brief understanding of how stuff works I'm
relying on you to point out whether this is even a valid suggestion.

-Michael

> Inheritance.
>
> CREATE TABLE parent (a, b, c);
>
> CREATE TABLE child (z) INHERITS (parent);
>
> ALTER TABLE parent ADD COLUMN (d);
>
> With the current implementation you now have column order a,b,c,d in the
> parent, and a,b,c,z,d in the child. This is seriously broken for a
> number of reasons, not least being that pg_dump can't realistically be
> expected to reproduce that state.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-12-18 02:22:55 Re: Tuple data
Previous Message Thomas Lockhart 2000-12-18 02:18:09 Re: Table name scope (was Re: Outer joins aren't working with views)