Re: scenario with a slow query - Mailing list pgsql-general

From Tom Lane
Subject Re: scenario with a slow query
Date
Msg-id 25162.1326910101@sss.pgh.pa.us
Whole thread Raw
In response to scenario with a slow query  (Volodymyr Kostyrko <c.kworr@gmail.com>)
Responses Transaction ID wraparound, Oracle style  (Igor Polishchuk <igor@powerreviews.com>)
Re: scenario with a slow query  (Volodymyr Kostyrko <c.kworr@gmail.com>)
List pgsql-general
Volodymyr Kostyrko <c.kworr@gmail.com> writes:
> Maybe I'm missing something but I have found a case when planner is
> unoptimal.

The planner knows next to nothing about optimizing FULL JOIN, and
I would not recommend holding your breath waiting for it to get better
about that, because there's basically no demand for the work that'd
be involved.  I'd suggest refactoring this query instead.  A nest of
full joins seems like a rather unintuitive way to get the result
anyway ...

            regards, tom lane

pgsql-general by date:

Previous
From: "A.M."
Date:
Subject: Re: Table permissions
Next
From: Igor Polishchuk
Date:
Subject: Transaction ID wraparound, Oracle style