Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification
От | Tom Lane |
---|---|
Тема | Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification |
Дата | |
Msg-id | 1505476.1600890483@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification
|
Список | pgsql-bugs |
Peter Geoghegan <pg@bowt.ie> writes: > Evidently nobody even tries to do this stuff. Yeah. But it would be particularly hard to do in Postgres, because of our resolutely extensible approach to data types and operators/functions. We'd have to devise some general-purpose APIs whereby a specific data type or function could decide whether a given transformation is valid or safe. It's not even very clear where would be the right place to lodge the knowledge. If you were really intent on making this happen, you could imagine for instance attaching a SupportRequestSimplify hook to "int4eq", which could transform "x - c1 = c2" into "x = c1 + c2" after verifying that the constant values wouldn't produce overflow. But this idea doesn't scale very well, since you'd really be talking about looking for a whole bunch of different possible rearrangements not just one. And it's unclear how you could avoid reimplementing a bunch of that logic for each different equality operator. On top of that, you would have little visibility into whether this was worth the cycles, since such code would be unlikely to know whether "x" is an indexable value or whether the expression occurs in a place where it could be used in an indexqual anyway. regards, tom lane
В списке pgsql-bugs по дате отправления: