"Kevin Grittner" <[EMAIL PROTECTED]> writes [offlist]:
> Attached is a pg_dump -c file with only the required rows (none of
> which contain confidential data), and 0.1% of the rows from the larger
> tables. It does show the same pattern of costing and plan choice.
Thanks for the test case. The f
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Since you were so confident it couldn't be the outer join, I went
> looking for what else I changed at the same time. I eliminated the code
> referencing that table, which contained an OR. I've seen ORs cause
> nasty problems with optimizers in the p
>>> On Wed, Feb 1, 2006 at 2:43 pm, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
>
> I took out the OR in the
> where clause, without eliminating that last outer join, and it
optimized
> fine.
FYI, with both sides of the OR separated:
explain analyze
SELECT "C".*
>>> On Wed, Feb 1, 2006 at 2:36 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>> I'm interested to poke at this ... are you in a position to provide
a
>>> test case?
>
>> I can't sup
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm interested to poke at this ... are you in a position to provide a
>> test case?
> I can't supply the original data, since many of the tables have
> millions of rows, with some of the data (related to juvenil
>>> On Wed, Feb 1, 2006 at 2:14 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>> ... expected an equivalent IN clause to work better. In fact, I'm
not
>>> clear why the planner isn't
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> ... expected an equivalent IN clause to work better. In fact, I'm not
>> clear why the planner isn't finding the cheapest plan (which it does
>> estimate as cheapest) from the IN version you posted.
> All I kno
>>> On Wed, Feb 1, 2006 at 1:34 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> We do have a few queries where PostgreSQL is several orders of
>> magnitude slower. It appears that the reason it is choosing a bad
plan
>> is
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> We do have a few queries where PostgreSQL is several orders of
> magnitude slower. It appears that the reason it is choosing a bad plan
> is that it is reluctant to start from a subquery when there is an outer
> join in the FROM clause.
AFAICT this c
We're converting from a commercial database product to PostgreSQL, and
generally things are going well. While the licensing agreement with the
commercial vendor prohibits publication of benchmarks without their
written consent, I'll just say that on almost everything, PostgreSQL is
faster.
We do
10 matches
Mail list logo
