Search Postgresql Archives

Re: referencing to "computed columns" in where clause

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux