| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: Pushing ScalarArrayOpExpr support into the btree index AM |
| Date: | 2011-10-16 18:26:38 |
| Message-ID: | 26790.1318789598@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Florian Pflug <fgp(at)phlo(dot)org> writes:
> On Oct16, 2011, at 19:09 , Tom Lane wrote:
>> That doesn't seem like the same thing at all, because the indexed column
>> is on different sides of the expression in the two cases. The situation
>> that I'm worried about is "indexedcolumn op ANY(arrayconstant)", and
>> what you're bringing up is "constant op ANY(indexedarraycolumn)".
> Couldn't we teach the main executor to push a ScalarArrayOpExpr down
> into the index AM if the operator belongs to the index's opclass, one
> side is indexed, and the other is constant?
Well, no, unless you're proposing to somehow implement the "constant op
ANY(indexedarraycolumn)" case in all the AMs. I don't see any practical
way to do it in btree, for one.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Pflug | 2011-10-16 18:36:36 | Re: Underspecified window queries in regression tests |
| Previous Message | Florian Pflug | 2011-10-16 18:13:31 | Re: Pushing ScalarArrayOpExpr support into the btree index AM |