Re: avoiding seqscan? - Mailing list pgsql-performance

From Christopher Browne
Subject Re: avoiding seqscan?
Date
Msg-id 60vfrbzkzs.fsf@dev6.int.libertyrms.info
Whole thread Raw
In response to avoiding seqscan?  (Palle Girgensohn <girgen@pingpong.net>)
Responses Re: avoiding seqscan?
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: TPC-R benchmarks
Next
From: Gaetano Mendola
Date:
Subject: Re: avoiding seqscan?