From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | jwieck(at)debis(dot)com, andreas(dot)zeugswetter(at)telecom(dot)at, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: order by and index path |
Date: | 1998-10-15 16:36:26 |
Message-ID: | m0zTqO2-000EBRC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> > 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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-10-15 16:42:00 | Re: [HACKERS] What about LIMIT in SELECT ? |
Previous Message | Martin | 1998-10-15 16:32:52 | Re: [HACKERS] Re: order by and index path |