Re: Different execution plans for semantically equivalent queries

Поиск
Список
Период
Сортировка
От Mikkel Lauritsen
Тема Re: Different execution plans for semantically equivalent queries
Дата
Msg-id ceef13d62cc11f34e221b688db527bb0@localhost
обсуждение исходный текст
Ответ на Re: Different execution plans for semantically equivalent queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Different execution plans for semantically equivalent queries  (Marti Raudsepp <marti@juffo.org>)
Список 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 по дате отправления:

Предыдущее
От: Shaun Thomas
Дата:
Сообщение: Re: Really really slow select count(*)
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Really really slow select count(*)