2008/1/30, Tom Lane <[EMAIL PROTECTED]>:
> "Dmitry Potapov" <[EMAIL PROTECTED]> writes:
> > 2008/1/25, Tom Lane <[EMAIL PROTECTED]>:
> >> It's hard to tell whether the planner is just being overoptimistic
> >> about the results of ANDing the three join conditions, or if one or
> >> more of the basi
"Dmitry Potapov" <[EMAIL PROTECTED]> writes:
> 2008/1/25, Tom Lane <[EMAIL PROTECTED]>:
>> It's hard to tell whether the planner is just being overoptimistic
>> about the results of ANDing the three join conditions, or if one or
>> more of the basic condition selectivities were misestimated.
> I w
Hello,
(Tom, sorry if you receive this letter twice. The first copy was
unintentionally sent with 'reply to sender only', I resend it to the
list, reply this one to keep the thread, please.)
2008/1/25, Tom Lane <[EMAIL PROTECTED]>:
> Well, there's our problem: an estimate of
"Dmitry Potapov" <[EMAIL PROTECTED]> writes:
> Sorry, it was just EXPLAIN. I can't run EXPLAIN ANALYZE on that
> (production) server, so I uploaded 3days old backup to a spare box and
> here's what I've got:
> -> Merge Join (cost=0.00..4955790.28 rows=1 width=59)
> (actual time=0.048..4
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> It doesn't look like an EXPLAIN ANALYZE output. Can you provide a real
> one (you should have a second set of numbers with EXPLAIN ANALYZE)?
Also, could we see the pg_stats rows for the columns being joined?
regards, tom lane
Dmitry,
On Jan 23, 2008 2:48 PM, Dmitry Potapov <[EMAIL PROTECTED]> wrote:
> EXPLAIN ANALYZE SELECT * FROM t1t2_view ORDER BY time_stamp ASC LIMIT 100:
>
> Limit (cost=13403340.40..13403340.40 rows=1 width=152)
It doesn't look like an EXPLAIN ANALYZE output. Can you provide a real
one (you shoul
I've got two huge tables with one-to-many relationship with complex
key. There's also a view, which JOINs the tables, and planner chooses
unoptimal plan on SELECTs from this view.
The db schema is declared as: (from on now, I skip the unsignificant
columns for the sake of simplicity)
CREATE TABL
