Re: Different execution plans for semantically equivalent queries - Mailing list pgsql-performance

From Mikkel Lauritsen
Subject Re: Different execution plans for semantically equivalent queries
Date
Msg-id ceef13d62cc11f34e221b688db527bb0@localhost
Whole thread Raw
In response to Re: Different execution plans for semantically equivalent queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Different execution plans for semantically equivalent queries  (Marti Raudsepp <marti@juffo.org>)
List pgsql-performance
Hi Tom et al,

Many thanks for your prompt reply - you wrote:

>> SELECT * FROM table t1 WHERE 0 = (SELECT COUNT(*) FROM table t2 WHERE
>>     t2.type = t1.type AND t2.timestamp > t1.timestamp)
>
> I suspect that *any* database is going to have trouble optimizing that.

Okay, I expected that much.

Just out of curiosity I've been looking a bit at the optimizer code
in PostgreSQL, and it seems as if it would be at least theoretically
possible to add support for things like transforming the query at
hand into the NOT EXISTS form; a bit like how = NULL is converted
to IS NULL.

Would a change like that be accepted, or would you rather try to
indirectly educate people into writing better SQL?

> You'd be well advised to lobby the persistence framework's authors to
> produce less brain-dead SQL.  The NOT EXISTS formulation seems to
> express what's wanted much less indirectly.

Will do :-)

For now I guess I'll hack it by wrapping a proxy around the JDBC
driver and rewriting the SQL on the fly; I encounter other bugs in
the persistence layer that are probably best handled that way as
well.

Best regards & thanks,
  Mikkel

pgsql-performance by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: Really really slow select count(*)
Next
From: Greg Smith
Date:
Subject: Re: Really really slow select count(*)