From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL OR performance |
Date: | 2008-11-17 09:52:21 |
Message-ID: | 331e40660811170152v219b5327hc1564da48dde2143@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2008/11/15 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> "=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <tivv00(at)gmail(dot)com> 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. There
> must be a huge number of duplicate join keys in that relation to make
> for such an increase though. Normally the planner avoids putting a
> table with lots of duplicates as the RHS of a merge, but if it doesn't
> have good statistics for the join key then it might not realize the
> problem.
>
OK, thanks for cleaning-up some mystery.
But, returning to original Q: Do anyone known why does it choose plan from *
OR-plan.txt* instead of *union-plan.txt*? The first is
cost=4588.13..960900482668.95, the latter is cost=266348.42..272953.14
according to statistics postgres have, so I suppose planner would select it
if it could evaluate it.
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2008-11-17 10:51:32 | Re: Improve Seq scan performance |
Previous Message | PFC | 2008-11-16 15:20:04 | Re: Performance Question |