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
