Re: avoiding seqscan?

--On måndag, september 29, 2003 11.12.55 -0400 Christopher Browne
<cbbrowne(at)libertyrms(dot)info> wrote:

> girgen(at)pingpong(dot)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.

You've got a point here. Still, with some queries, since the data is pretty
static and we know much about its distribution over the tables, we had to
explicitally tell postgresql how to optimze the queries to get them fast
enough. We cannot afford any queries to be more than fractions of seconds,
really.

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

Depends, I actually don't agree on this, but I guess it depends on which
syntax you're used to.

> 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.

Oh, but of course. For the queries I refer to, optimization actually proved
necessary, believe me :-)

Cheers,
Palle