From: Richard Huxton <dev@archonet.com>
To: Віталій Тимчишин <tivv00@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL OR performance
Date: Thu, 06 Nov 2008 16:44:05 +0000
Message-ID: <49131ED5.80307@archonet.com> (raw)
In-Reply-To: <331e40660811060833l49bf837em41ca88d4b2061ea1@mail.gmail.com>
References: <331e40660811050312u552cab53ifa88e493e1c4f7ac@mail.gmail.com>
<1225902700.1432.53.camel@jdavis>
<331e40660811060246m51df553egd4e2ba91f08d1434@mail.gmail.com>
<29e3942f0811060426k5fe34b1av401a2dba62e4ae3c@mail.gmail.com>
<331e40660811060833l49bf837em41ca88d4b2061ea1@mail.gmail.com>
Віталій Тимчишин wrote:
> As you can see from other plans, it do have all the indexes to perform it's
> work fast (when given part by part). It simply do not wish to use them. My
> question: Is this a configuration problem or postgresql optimizer simply
> can't do such a query rewrite?
I must admit, I haven't managed to figure out what your query is trying
to do, but then that's a common problem with autogenerated queries.
The main question that needs answering is why the planner thinks you're
going to get 1.3 billion rows in the "or" query:
"Nested Loop (cost=4588.13..960900482668.95 rows=1386158171 width=32)"
You don't show "explain analyse" for this query, so there's no way of
knowing how many rows get returned but presumably you're expecting
around 88000. What does "explain analyse" return?
--
Richard Huxton
Archonet Ltd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dev@archonet.com, tivv00@gmail.com
Subject: Re: PostgreSQL OR performance
In-Reply-To: <49131ED5.80307@archonet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox