From: | Constantin Teodorescu <teo(at)flex(dot)ro> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] An optimisation question |
Date: | 1999-08-30 15:40:51 |
Message-ID: | 37CAA603.E8E5C2E1@flex.ro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> That's fixed for 6.6. A workaround that partially solves the problem
> for 6.5 is to add a dummy WHERE clause referencing the ORDER-BY item:
> select data from valori where data > '1/1/1800'
> order by data limit 1;
> The WHERE is needed to get the 6.5 optimizer to consider the index
> at all. In a quick test it seems this works for normal order but not
> DESC order... you could try applying the backwards-index patch that
> someone (Hiroshi or Tatsuo, I think) posted recently.
Yeap , I will search for it.
> There's no prospect of that happening anytime soon, I fear; there is no
> connection between aggregate functions and indexes in the system, and
> no easy way of making one.
Understand that, but.
Selects that deal ONLY with columns included in an index should operate
exclusively on that index and return the results. Example : select
sum(price) , price*1.2, max(price) from products , assuming that price
is included in an index it would be less cost to scan the index rather
than the whole table.
I remember that Paradox tables had indexes and the index was also a
Paradox table or some sort of that. Internally it's possible that a
number of procedures related to tables could be applied to indexes. So,
a sum(price) from a_table could be easily switched to be done on any
index that contain the price field.
What do you think?
Constantin Teodorescu
FLEX Consulting BRaila, ROMANIA
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1999-08-30 17:03:09 | Re: [HACKERS] PostgreSQL 6.5.2 |
Previous Message | Hub.Org News Admin | 1999-08-30 15:07:08 |