From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | André Volpato <andre(dot)volpato(at)ecomtecnologia(dot)com(dot)br> |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Hash join in 8.3 |
Date: | 2007-12-13 18:19:17 |
Message-ID: | 17340.1197569957@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
=?ISO-8859-1?Q?Andr=E9_Volpato?= <andre(dot)volpato(at)ecomtecnologia(dot)com(dot)br> writes:
> Besides the (expected) weak guess on rows for both servers on seq scan
> on jtest, there is something nasty with [2] that prevents the planner to
> use the index.
There isn't anything "preventing" either version from choosing any of
the three plans, as you can easily prove for yourself by experimenting
with enable_nestloop/enable_mergejoin/enable_hashjoin. The cost
estimates seem close enough that random variations in ANALYZE stats
would change which one looks cheapest.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | robert | 2007-12-13 18:38:36 | Finding bad bye in "invalid byte sequence" error |
Previous Message | André Volpato | 2007-12-13 17:55:36 | Hash join in 8.3 |