From: | mark(at)mark(dot)mielke(dot)cc |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Ilia Kantor <ilia(at)obnovlenie(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: effective SELECT from child tables |
Date: | 2005-10-02 18:25:53 |
Message-ID: | 20051002182553.GA13522@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
If one defines a restriction such that 'COLUMN = VALUE' for a specific
table, in a theoretical sort of model that completely ignores
implementation difficulty, or changes to the restriction, I think it
would be safe to not store COLUMN in the tuple. If the tuple is
stored, then COLUMN = VALUE, so when fetched, the value will be VALUE.
Back to the real world, this would be difficult to implement without
treating the column special from the point of table creation, and
preventing the restriction from being altered without re-building
the table... :-)
Cheers,
mark
--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-10-02 18:43:17 | External Sort timing debug statements |
Previous Message | Greg Stark | 2005-10-02 15:43:46 | Re: effective SELECT from child tables |