Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Interesting. The inconsistency you're seeing is a result of GEQO. I
> > would have hoped that it would have produced a better quality plan
> > more often, but apparently not. On my system, the regular query
> > optimizer handily beats G
Kris Jurka <[EMAIL PROTECTED]> writes:
> Looking at the differences in statistics before and after the ANALYZE the
> only differences are in correlation. This comes from initdb around line
> 1046...
> "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null < ANALYZE;
> VACUUM FULL FREEZE;
> EOF
> Co
On Thu, 19 Sep 2002, Kris Jurka wrote:
>
> On Thu, 19 Sep 2002, Tom Lane wrote:
>
> > Kris Jurka <[EMAIL PROTECTED]> writes:
> > > While adding schema support to the JDBC Driver, I came across a query
> > > which occasionally generates some spectacularly bad plans.
> >
> > Hm, does an ANALYZE he
Neil Conway <[EMAIL PROTECTED]> writes:
> Interesting. The inconsistency you're seeing is a result of GEQO. I
> would have hoped that it would have produced a better quality plan
> more often, but apparently not. On my system, the regular query
> optimizer handily beats GEQO for this query: it pro
On Thu, 19 Sep 2002, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > While adding schema support to the JDBC Driver, I came across a query
> > which occasionally generates some spectacularly bad plans.
>
> Hm, does an ANALYZE help?
>
Yes, it does, but I don't understand why. The
Kris Jurka <[EMAIL PROTECTED]> writes:
> While adding schema support to the JDBC Driver, I came across a
> query which occasionally generates some spectacularly bad plans.
Interesting. The inconsistency you're seeing is a result of GEQO. I
would have hoped that it would have produced a better qua
Maybe not nice, but there's only 32 (64 now?) of them...
JOIN pg_attribute WHERE attnum IN (conkeys[1], conkeys[2], conkeys[3],
..., conkeys[32])
Great fun...
On Thu, 2002-09-19 at 18:31, Kris Jurka wrote:
>
> Well I was really hoping pg_constraint would solve all my problems, but
> since cont
Kris Jurka <[EMAIL PROTECTED]> writes:
> While adding schema support to the JDBC Driver, I came across a query
> which occasionally generates some spectacularly bad plans.
Hm, does an ANALYZE help?
regards, tom lane
---(end of broadcast)-
Well I was really hoping pg_constraint would solve all my problems, but
since contrib/array is not installed by default the conkeys and confkeys
columns aren't terribly useful because they can't be joined to
pg_attribute.
Also there is not a column to tell you the unique constraint that
supports
Congratulations. That is the largest plan I have ever seen. ;-)
---
Kris Jurka wrote:
> While adding schema support to the JDBC Driver, I came across a query
> which occasionally generates some spectacularly bad plans.
While adding schema support to the JDBC Driver, I came across a query
which occasionally generates some spectacularly bad plans. I have
attached the query and explain analyze outputs against today's cvs head
for queries that take between 9 and 845941 msec. In the JDBC Driver I
will specify a
11 matches
Mail list logo
