> > > 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 we lack a definition here:
> >
> > logical number: the order of columns when doing select *
> > physical number: the position inside the heap tuple (maybe with
> > offset)
> >
> > All views and plans and index definitions and most everyting else
> > needs to reference the logical number.
>
> Huh? If I have an index on the first two columns of a table,
> it's going
> to refernce columns 1 and 2.
>
> If you alter the table to put a column in front of those two, the new
> column will be physical 3, logical 1.
No, you change pg_index to now contain 2,3.
> If the index references logical numbers, the index has just been
> broken. If the index references physical numbers, everything works
> without changes.
yup, sinval
> Same with views, if you use logical numbers you have to rebuild the
> view each time. Why bother, when physical numbers work and don't have
> that problem?
Because it would imho be a nightmare to handle ...
Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
