Added to TODO:
> o Allow column display reordering by recording a display,
> storage, and permanent id for every column?
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
>
---
Jim
On Thu, Dec 21, 2006 at 11:43:27AM -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> You could make a case that we need *three* numbers: a permanent column
> >> ID, a display position, and a storage position.
>
> > Could this not be handled by some catalo
> >> You could make a case that we need *three* numbers: a permanent
column
> >> ID, a display position, and a storage position.
>
> > Could this not be handled by some catalog fixup after an add/drop?
If we
> > get the having 3 numbers you will almost have me convinced that this
> > might be t
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Actually, the more I think about it the more I think that 3 numbers
>> might be the answer. 99% of the code would use only the permanent ID.
> Don't we already have such a permanent number -- just one we don't use
Tom Lane <[EMAIL PROTECTED]> writes:
> Actually, the more I think about it the more I think that 3 numbers
> might be the answer. 99% of the code would use only the permanent ID.
Don't we already have such a permanent number -- just one we don't use
anywhere in the data model? Namely the oid of
Tom Lane wrote:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Display position would be used in *exactly* one place, namely while
expanding "SELECT foo.*" --- I can't think of any other part of the
backen
Martijn van Oosterhout writes:
> I was envisiging the physical number to be fixed and immutable (ie
> storage position = permanent position).
There are two different problems being discussed here, and one of them
is insoluble if we take that position: people would like the system to
automatically
On Thu, Dec 21, 2006 at 11:15:38AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Can we? For anything of any permenence (view definitions, rules,
> > compiled functions, plans, etc) you're going to want the physical
> > number, for the same reason we store the oids of functions and t
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You could make a case that we need *three* numbers: a permanent column
>> ID, a display position, and a storage position.
> Could this not be handled by some catalog fixup after an add/drop? If we
> get the having 3 numbers you will
Tom Lane wrote:
Martijn van Oosterhout writes:
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Really? To me that's one of a large number of questions that are
unresolved about how we'd do this. You can make a case for either
choice in quite a number of places.
> > > The thing is, physical index numbers has meaning, the logical
index
> > > number does not. In a view definition we're going to store the
> > > physical index, not the logical one, for example. We don't want
> > > rearranging columns to invalidate view definitions or plans.
> >
> > I think w
Martijn van Oosterhout writes:
> On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
>> Really? To me that's one of a large number of questions that are
>> unresolved about how we'd do this. You can make a case for either
>> choice in quite a number of places.
> Can we? For anything of an
On Thu, Dec 21, 2006 at 05:06:53PM +0100, Zeugswetter Andreas ADI SD wrote:
> > The thing is, physical index numbers has meaning, the logical index
> > number does not. In a view definition we're going to store the
> > physical index, not the logical one, for example. We don't want
> > rearranging
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > The thing is, physical index numbers has meaning, the logical index
> > number does not. In a view definition we're going to store the physical
> > index, not the logical one, for example.
>
> Really?
> > I don't think we should expose the offset to user view at all - this
is
> > just for internal use, no?
>
> The thing is, physical index numbers has meaning, the logical index
> number does not. In a view definition we're going to store the
physical
> index, not the logical one, for example.
Martijn van Oosterhout writes:
> The thing is, physical index numbers has meaning, the logical index
> number does not. In a view definition we're going to store the physical
> index, not the logical one, for example.
Really? To me that's one of a large number of questions that are
unresolved ab
On Thu, Dec 21, 2006 at 10:27:12AM -0500, Andrew Dunstan wrote:
> >Um, surely you meant "offset the physical numbers". Imho the logical
> >numbers
> >need to stay 1-n, because those numbers are used way more often and are
> >more user visible than the physical.
> >
> >
> >
>
> I don't think we
Zeugswetter Andreas ADI SD wrote:
I'm not sure how much you can do with typing. Things like heap_getattr
are macros, and thus untyped. Most places use attr as an index to an
array, which also can't be type checked.
If you switched everything over to inline functions you might
get it to
work, b
> I'm not sure how much you can do with typing. Things like heap_getattr
> are macros, and thus untyped. Most places use attr as an index to an
> array, which also can't be type checked.
>
> If you switched everything over to inline functions you might
> get it to
> work, but that's about it.
>
Andrew Dunstan wrote:
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Force references to go through macros which implement the lookup
for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
On Wed, Dec 20, 2006 at 09:15:05AM -0500, Stephen Frost wrote:
> > It doesn't really address the question of how you know which one to
> > use at any particular line of code; or even more to the point, what
> > mechanism will warn you if you use the wrong one.
>
> That'd be the point of doing the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume space waste will be mostly fixed when we have 0/1 byte headers
> for varlena data types.
Hardly. int float timestamp etc types will all still have alignment issues.
regards, tom lane
---(end of
Andrew Dunstan wrote:
Or we could divide the positive number space in two, by starting at 2^14
(attnums are int2). Then a simple bitmask test would work to distinguish
them.
Perhaps divide-by-four, then it would be possible to have calculated
columns (as mentioned recently on one of the lis
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> This isn't really a compromise. Remember that this discussion started
> with consideration of optimal record layout (minimising space use by
> reducing or eliminating alignment padding). The above proposal really
> does nothing for that.
While I agr
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
> Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> > If you can show me a reasonably bulletproof or machine-checkable way to
> > keep the two kinds of column numbers distinct, I'd be all for it.
>
> The only way I can see is
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Force references to go through macros which implement the lookup for
the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really addre
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Force references to go through macros which implement the lookup for the
> > appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
> > PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
>
> It doesn't really
Martijn van Oosterhout wrote:
On Wed, Dec 20, 2006 at 07:20:14AM -0600, Kenneth Marshall wrote:
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or machine-checkab
Am Mittwoch, 20. Dezember 2006 14:20 schrieb Kenneth Marshall:
> On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
> > Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> > > If you can show me a reasonably bulletproof or machine-checkable way to
> > > keep the two kinds of col
On Wed, Dec 20, 2006 at 07:20:14AM -0600, Kenneth Marshall wrote:
> On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
> > Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> > > If you can show me a reasonably bulletproof or machine-checkable way to
> > > keep the two kinds of
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> If you can show me a reasonably bulletproof or machine-checkable way to
> keep the two kinds of column numbers distinct, I'd be all for it.
The only way I can see is to make the domains of the numbers distinct.
--
Peter Eisentraut
http://d
On Tue, Dec 19, 2006 at 11:29:24PM -0500, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Force references to go through macros which implement the lookup for the
> > appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
> > PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
>
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Force references to go through macros which implement the lookup for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address the question of how
Stephen Frost <[EMAIL PROTECTED]> writes:
> Force references to go through macros which implement the lookup for the
> appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
> PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address the question of how you know which one to
* Tom Lane ([EMAIL PROTECTED]) wrote:
> If you can show me a reasonably bulletproof or machine-checkable way to
> keep the two kinds of column numbers distinct, I'd be all for it. But
> without that, the answer will remain no.
Force references to go through macros which implement the lookup for t
Robert Treat <[EMAIL PROTECTED]> writes:
> On Tuesday 19 December 2006 11:25, Martijn van Oosterhout wrote:
>> A patch to allow seperate physical and logical orderings was submitted
>> and rejected. Unless something has changed on that front, any
>> discussion in this direction isn't really useful.
On Tuesday 19 December 2006 11:25, Martijn van Oosterhout wrote:
> On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
> > Sure, but the only sane way I can think of to do that would be have
> > separate logical and physical orderings, with a map between the two. I
> > guess we'd need t
On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
> Sure, but the only sane way I can think of to do that would be have
> separate logical and physical orderings, with a map between the two. I
> guess we'd need to see what the potential space savings would be and
> establish what t
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as
39 matches
Mail list logo
