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 | 544018.1600464150@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16624: Query Optimizer - Performance bug related to predicate simplification (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification
Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > We are developing a tool for automatically finding performance bugs in > PostgreSQL. Our key insight is that given a pair of semantic equivalent > queries, a robust DBMS should return the same result within a similar > execution time. Significant time difference suggests a potential performance > bug in the DBMS. Unfortunately, that's a viewpoint that is not going to win you a lot of converts. > First query: > SELECT "ps_suppkey" > FROM "partsupp" > WHERE "ps_partkey" = 1486; > Second query: > SELECT "ps_suppkey" > FROM "partsupp" > WHERE "ps_partkey" + 1486 = 2972; Sure, in theory the optimizer could rearrange that to "WHERE ps_partkey = 2972 - 1486" and thus still have an indexable condition. In practice, we have essentially no interest in doing so. It would require vastly more semantic knowledge than the optimizer has got, and looking for such cases would consume lots of planner cycles that would be better spent elsewhere. If you want to complain that that makes Postgres' optimizer "not robust", you're entitled to that opinion. But it's very unlikely to change in the foreseeable future. We expect that if a user cares about the performance of a particular query, they'll be willing to write it in a form that the optimizer can deal with. regards, tom lane
В списке pgsql-bugs по дате отправления: