Re: How to refer to computed columns from other computed columns?

From: Thom Brown <thom(at)linux(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Matthew Wilson <matt(at)tplus1(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: How to refer to computed columns from other computed columns?
Date: 2010-08-16 18:51:49
Message-ID: AANLkTinH9RsTH2tJrwCf8UJKhCmn8h5Lv-t+H_hc5AFb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2010/8/16 Boszormenyi Zoltan <zb(at)cybertec(dot)at>:
> Matthew Wilson írta:
>> On Mon Aug 16 10:26:36 2010, Tom Lane wrote:
>>
>>> Matthew Wilson <matt(at)tplus1(dot)com> writes:
>>>
>>>> All I can come up with so far is to use a view and then another view on
>>>> top of that one:
>>>>
>>> Note that you don't actually need a view, as you can just write the
>>> subselect in-line:
>>>
>>>      select a, b, c,
>>>      case when c < 0 then 'no'
>>>      else 'yes'
>>>      end as d
>>>      from (select a, b, a - b as c from foo) as v1;
>>>
>>> This is the standard method for avoiding repeat calculations in SQL.
>>>
>>> One thing to keep in mind is that the planner will usually try to
>>> "flatten" a nested sub-select (and whether it was written out manually
>>> or pulled from a view does not matter here).  This will result in the
>>> sub-select's expressions getting inlined into the parent, so that the
>>> calculations will actually get done more than once.  If you're trying
>>> to reduce execution time not just manual labor, you may want to put an
>>> "offset 0" into the sub-select to create an optimization fence.  But
>>> test whether that really saves anything --- if there are bigger joins
>>> or additional WHERE conditions involved, you can easily lose more than
>>> you gain by preventing flattening.
>>>
>>>                      regards, tom lane
>>>
>>>
>>
>> Thanks so much for the help!
>>
>> I don't care if the code is rearranged so that c is replaced with an
>> inline definition during compilation.  I'm not concerned about
>> efficiency here.  I just don't want to have to redefine it manually over
>> and over again, because I know that as I update how c is defined, I'll
>> forget to update it everywhere.
>>
>> Maybe sql needs a preprocessing macro language like C.
>>
>
> Or maybe we can dust off my GENERATED column patch
> I posted here in 2006. :-)
>
> Best regards,
> Zoltán Böszörményi
>

You mean this?:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php
And this?: http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php
And this?: http://archives.postgresql.org/pgsql-patches/2007-04/msg00107.php

--
Thom Brown
Registered Linux user: #516935

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2010-08-16 20:18:06 Re: How to refer to computed columns from other computed columns?
Previous Message Boszormenyi Zoltan 2010-08-16 18:45:07 Re: How to refer to computed columns from other computed columns?