| From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
| Subject: | Re: Mini improvement: statement_cost_limit |
| Date: | 2008-08-15 15:47:07 |
| Message-ID: | 48A5A4FB.4070907@cheapcomplexdevices.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Josh Berkus wrote:
>> ...simple web applications, where
>> queries are never supposed to take more than 50ms. If a query turns up
>> with an estimated cost of 10000000000, then you know something's wrong;
>> ...
>
> How about a simpler approach that throws an error or warning for
> cartesian products? That seems fool-proof.
Seems less fool-proof to me.
Sometimes cartesian products produce plans that run 200 times
faster than plans that don't use the cartesian product.
The first link below shows a cartesian join that took 1.1
seconds (within the range of OK for some web apps), while
plans for the same query that don't use one took 200 seconds.
http://archives.postgresql.org/pgsql-performance/2008-03/msg00391.php
http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php
http://archives.postgresql.org/pgsql-performance/2008-03/msg00361.php
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2008-08-15 16:12:17 | Re: Mini improvement: statement_cost_limit |
| Previous Message | Bruce Momjian | 2008-08-15 15:16:23 | Re: Mini improvement: statement_cost_limit |