Re: [HACKERS] Re: order by and index path

>
> >     could return at max 8999 tuples and
> >
> >         WHERE key > 50 AND key < 70
> >
> >     has  a  maximum  of  998  result  tuples.  This  would be the
> >     information required to make the right decision for the  case
> >     where all rows selected are wanted.
> >
> >     We  do  not  have  this statistical information. So the whole
> >     thing is at this time academic.
>
> But we do have statistical information in pg_statistic if you run vacuum
> analyze.

    Nice  (forgot  that  - pardon), anyway only having lowest and
    highest key values isn't enough to make a  useful  estimation
    about  how  many  rows an indexqual will return. If we change
    pg_statistic in a way that  more  keys  can  get  stored  per
    relation/attribute,  then  the  optimizer  would  have a real
    chance on it.

    I have

        starelid
        staattnum
        staitupno
        staop
        stakey

    in mind, where staitupno tells the position of the key  in  a
    complete index scan. Then it becomes the place to fill in the
    key range information as described in my posting.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #