Re: Predicate migration on complex self joins

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

In response to

Browse pgsql-hackers by date

  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