From: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
---|---|
To: | decibel <decibel(at)decibel(dot)org> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Predicate migration on complex self joins |
Date: | 2009-07-13 20:58:24 |
Message-ID: | 3073cc9b0907131358y1df4058bn752acbec30d8faf3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 13, 2009 at 3:48 PM, decibel<decibel(at)decibel(dot)org> wrote:
> On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote:
>>
>> Not just because of this but I wonder if we might benefit from an
>> optimizer setting specifically aimed at the foolishnesses of
>> automatically generated SQL.
>
>
> +1. And it's not just ORMs that do stupid things, I've seen crap like this
> come out of users too (not this exact case, but similar).
>
i've this come from users most of the time...
the few systems i have seen that generate sql, try to avoid using
complex queries and make simple ones and the JOIN them at the app
level...
> Perhaps what we really want is an "optimization level" GUC so that users can
> tell the backend how much overhead they want the optimizer to spend on
> trying to work around stupidity... :)
i wonder what the levels have to be:
- smart_sql
- application_generated_sql
- normal_user_sql
- xtremely_stupid_sql
- what_the_hell_sql
;)
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
From | Date | Subject | |
---|---|---|---|
Next Message | A.M. | 2009-07-13 21:00:21 | Re: [RFC] obtaining the function call stack |
Previous Message | decibel | 2009-07-13 20:51:58 | Re: [RFC] obtaining the function call stack |