Re:

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bradley Baetz <bbaetz(at)student(dot)usyd(dot)edu(dot)au>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re:
Date: 2002-02-25 16:48:22
Message-ID: 21639.1014655702@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Bradley Baetz <bbaetz(at)student(dot)usyd(dot)edu(dot)au> writes:
> I'm having some problems with query optimisation, using postgresql 7.2.

It looks like on your hardware, seqscans are much cheaper relative to
indexscans than the optimizer is expecting. Note the ratios of cost
estimates to actual runtimes. You might care to experiment with the
optimizer parameters, such as random_page_cost, to see if you can get
closer to the actual behavior of your configuration.

> Also, in this case it would be better to use an inner join rather than a
> left join. Since there is a condition on cc.who which won't match NULL
> values from the cc table, an inner join should give the same results,
> shouldn't it?

It's not so much that you want an inner join as that you want to be able
to figure out that the cc.who=86 condition could be applied before
joining rather than after. I have not thought hard about how the
optimizer could determine whether this is a safe transformation. In
general it's obviously not safe when dealing with an outer join --- but
maybe in some cases we could allow it. Can anyone propose a rule?

regards, tom lane

PS: this discussion would be better suited for pgsql-hackers, I think.

In response to

  • at 2002-02-23 10:21:07 from Bradley Baetz

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-25 16:54:52 Re: patch queue
Previous Message Tom Lane 2002-02-25 16:34:10 Re: My "TOAST slicing" patch -explanation

Browse pgsql-sql by date

  From Date Subject
Next Message Samuel J. Sutjiono 2002-02-25 17:17:01 Sort problem
Previous Message Hunter, Ray 2002-02-25 16:36:11 Database Setup