2008/11/15 Tom Lane <[EMAIL PROTECTED]>
> "=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> > I am not. I can't see how materialize can multiply number of rows it gets
> > from sort by 100.
>
> Is it the right-hand input of a merge join? If so you're looking at
> mark/rest
"=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> I am not. I can't see how materialize can multiply number of rows it gets
> from sort by 100.
Is it the right-hand input of a merge join? If so you're looking at
mark/restore rescans, ie, repeated fetches of the same tuples
2008/11/7 Richard Huxton <[EMAIL PROTECTED]>
> But it's this materialize that's taking the biggest piece of the time.
>
> > " -> Materialize (cost=469981.13..498937.42 rows=2316503 width=30)
> > (actual time=15915.639..391938.338 rows=242752539 loops=1)"
>
> 15.9 seconds to 391.9 seconds. That'
Sorry, for delayed response - It was very busy week.
2008/11/7 David Wilson <[EMAIL PROTECTED]>
> On Fri, Nov 7, 2008 at 4:14 AM, Віталій Тимчишин <[EMAIL PROTECTED]> wrote:
> > "Merge Join (cost=518771.07..62884559.80 rows=1386158171 width=32)
> (actual
> > time=30292.802..755751.242 rows=34749
Віталій Тимчишин wrote:
> I am sorry, I've emptied atom_match table, so one part produce 0 result, but
> anyway here is explain:
David's right - the total estimate is horribly wrong
> "Merge Join (cost=518771.07..62884559.80 rows=1386158171 width=32) (actual
> time=30292.802..755751.242 rows=347
On Fri, Nov 7, 2008 at 4:14 AM, Віталій Тимчишин <[EMAIL PROTECTED]> wrote:
> "Merge Join (cost=518771.07..62884559.80 rows=1386158171 width=32) (actual
> time=30292.802..755751.242 rows=34749 loops=1)"
Have you tried increasing the default_statistics_target? The planner
is expecting 1.3 billion
>
>
> Yes, the query should output exactly same result as in "Union" plan. I will
> run "slow" explain analyze now and will repost after it will complete
> (tomorrow?).
> BTW: I'd say planner should think rows estimated as sum of "ORs" estimation
> minus intersection, but no more then sum or ORs (i
2008/11/6 Richard Huxton <[EMAIL PROTECTED]>
> Віталій Тимчишин 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 opti
As far as i know if you created the indexes properly and postgres sees that
it will give some improvement he will use those.
- Look at the page of index creation that we may be forgeting some thing.
http://www.postgresql.org/docs/8.3/static/indexes.html
I have to go to the hospital know. Tomorro
Віталій Тимчишин 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 admi
2008/11/6 Helio Campos Mello de Andrade <[EMAIL PROTECTED]>
> For what i see in four OR-plan.txt tou are doing too much "sequencial scan"
> . Create some indexes for those tables using the fields that you use an it
> may help you.
>
> OBS: If you already have lots of indexes in your tables it may
For what i see in four OR-plan.txt tou are doing too much "sequencial scan"
. Create some indexes for those tables using the fields that you use an it
may help you.
OBS: If you already have lots of indexes in your tables it may be a good
time for you re-think your strategy because it´s ot working.
My main message is that I can see this in many queries and many times. But
OK, I can present exact example.
2008/11/5 Jeff Davis <[EMAIL PROTECTED]>
> On Wed, 2008-11-05 at 13:12 +0200, Віталій Тимчишин wrote:
> > For a long time already I can see very poor OR performance in
> > postgres.
> > If
On Wed, 2008-11-05 at 13:12 +0200, Віталій Тимчишин wrote:
> For a long time already I can see very poor OR performance in
> postgres.
> If one have query like "select something from table where condition1
> or condition2" it may take ages to execute while
> "select something from table where cond
"=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> For a long time already I can see very poor OR performance in postgres.
If you would provide a concrete example rather than handwaving, we might
be able to offer some advice ...
regards, tom lane
--
Hello.
For a long time already I can see very poor OR performance in postgres.
If one have query like "select something from table where condition1 or
condition2" it may take ages to execute while
"select something from table where condition1" and "select something from
table where condition2" are
16 matches
Mail list logo
