| From: | Sam Mason <sam(at)samason(dot)me(dot)uk> | 
|---|---|
| To: | pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: referencing to "computed columns" in where clause | 
| Date: | 2008-01-31 12:20:36 | 
| Message-ID: | 20080131122036.GB1887@frubble.xen.chris-lamb.co.uk | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
On Tue, Jan 29, 2008 at 06:49:50PM +0100, Ivan Sergio Borgonovo wrote:
> On Tue, 29 Jan 2008 17:17:39 +0000 Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:
> > I've tended to do:
> > 
> >   SELECT *
> >   FROM (
> >     SELECT "complicated expression" AS pippo) x
> >   WHERE pippo  < 12;
> 
> It risk to be much harder to rewrite for dumber DB than repeating the
> "complicated expression".
If you're worrying about how the various implementations handle the
cases then I'd suggest testing the code in each one and see how they
handle it.
> Does it come with some extra cost/improvement in term of performance
> compared to:
> - repeating the code of "complicated expression"
Most reasonable databases will expand subselects where possible.
Optimisation is always a tradeoff between different factors--one of
these being maintainability.
> - put it in a function with the proper "attributes" (I'd say
> IMMUTABLE in the above case)
That's almost never going to be a win; rewriting sub-selects is almost
always going to be easier than rewriting stored procedures.
> I've some argument for all cases but it should depend on the
> implementation.
My recommendation is generally to use the easiest solution that works
now and only worry about things when they actually fail.
Sam
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chander Ganesan | 2008-01-31 12:21:37 | Re: [GENERAL] Backup | 
| Previous Message | jiniusatwork-postgresql | 2008-01-31 12:08:51 | Re: Performance problems with Postgresql/ZFS/Non-global zones on Solaris? |