>
> > 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) #
