Skip site navigation (1) Skip section navigation (2)

Re: avoiding seqscan?

From: Palle Girgensohn <girgen(at)pingpong(dot)net>
To: Christopher Browne <cbbrowne(at)libertyrms(dot)info>,pgsql-performance(at)postgresql(dot)org
Subject: Re: avoiding seqscan?
Date: 2003-09-29 21:27:48
Message-ID: 33670000.1064870868@palle.girgensohn.se (view raw or flat)
Thread:
Lists: pgsql-performance

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


In response to

pgsql-performance by date

Next:From: Palle GirgensohnDate: 2003-09-29 21:31:54
Subject: Re: advice on raid controller
Previous:From: scott.marloweDate: 2003-09-29 19:40:16
Subject: Re: advice on raid controller

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group