| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jules Bean <jules(at)jellybean(dot)co(dot)uk> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Constant propagation and similar issues |
| Date: | 2000-09-11 16:22:39 |
| Message-ID: | 14331.968689359@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jules Bean <jules(at)jellybean(dot)co(dot)uk> writes:
> However, it does seem to me that PostgreSQL /should/
> be able to make these transformations (at least, it should IMO
> recognise that given an expression of the form a + b - c + d < e - f
> + g where exactly one of a..g is a column name, and the rest are
> constant, that is a candidate for using the index).
Mumble. I think that'd be a very difficult thing to do without losing
the datatype extensibility of the system. Right now, the only reason
that "a < b" is considered indexable is that the optimizer has a table
that tells it "<" is an indexable operator for btree indexes with
certain datatypes (opclasses). Neither the optimizer nor the btree code
has any real understanding of the relationships between "<" and "-", say.
There is no part of the system anywhere with understanding of algebraic
identities like "a - b < c can be transformed to a < b + c", and no way
I can see to add such knowledge without making it *substantially* harder
to add new datatypes and operators.
Between that and the runtime that would be wasted during typical queries
(IMHO searching for rearrangeable clauses would usually be fruitless),
I really doubt that this is a good goal to pursue in Postgres.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jules Bean | 2000-09-11 16:28:31 | Re: Constant propagation and similar issues |
| Previous Message | Brook Milligan | 2000-09-11 16:22:10 | Re: pg_dump failed sanity check and user defined types |