Re: avoiding seqscan?

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: avoiding seqscan?
Дата
Msg-id 60vfrbzkzs.fsf@dev6.int.libertyrms.info
обсуждение исходный текст
Ответ на avoiding seqscan?  (Palle Girgensohn <girgen@pingpong.net>)
Ответы Re: avoiding seqscan?  (Palle Girgensohn <girgen@pingpong.net>)
Список pgsql-performance
girgen@pingpong.net (Palle Girgensohn) writes:
> Will that make a difference? From what I've seen, it does not make
> much difference, but I have seen queries speed up when rewritten
> explicit joins. I guess it depends on other things, but is it really
> so that the explicit joins are bad somehow? Do you have any pointers
> to documentation about it, if so?

The problem is that if you expressly specify the joins, the query
optimizer can't choose its own paths.  And while that may not be
better at the moment, it is quite possible that when you upgrade to a
newer version, those queries, if "not join-specified," could
immediately get faster.

I would expect that the query that uses implicit joins will be clearer
to read, which adds a little further merit to that direction.

That goes along with the usual way that it is preferable to optimize
things, namely that you should start by solving the problem as simply
as you can, and only proceed to further optimization if that actually
proves necessary.  Optimization efforts commonly add complexity and
make code more difficult to maintain; that's not the place to start if
you don't even know the effort is necessary.
--
(format nil "~S@~S" "cbbrowne" "libertyrms.info")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: TPC-R benchmarks
Следующее
От: Gaetano Mendola
Дата:
Сообщение: Re: avoiding seqscan?