Re: Query Optimizer Failure / Possible Bug

    Noticed this problem,too.
    You can always make the calculation you want done once inside a set
returning function so it'll behave like a table, but that's ugly.

On Mon, 28 Mar 2005 16:14:44 +0200, Hannes Dorbath
<light@theendofthetunnel.de> wrote:

> hm, a few days and not a single reply :|
>
> any more information needed? test data? simplified test case? anything?
>
>
> thanks
>
>
> Hannes Dorbath wrote:
>> The query and the corresponding EXPLAIN is at
>>  http://hannes.imos.net/query.txt
>>  I'd like to use the column q.replaced_serials for multiple calculations
>> in the SELECT clause, but every time it is referenced there in some way
>> the whole query in the FROM clause returning q is executed again.
>>  This doesn't make sense to me at all and eats performance.
>>  If this wasn't clear enough, for every
>>  q.replaced_serials <insert_random_calculation> AS some_column
>>  in the SELECT clause there is new block of
>>  ---------------------------------------------------------------
>> ->  Aggregate  (cost=884.23..884.23 rows=1 width=0)
>>       ->  Nested Loop  (cost=0.00..884.23 rows=1 width=0)
>>             ->  Index Scan using ix_rma_ticket_serials_replace on
>>                         rma_ticket_serials rts  (cost=0.00..122.35
>>                         rows=190 width=4)
>>                   Index Cond: ("replace" = false)
>>             ->  Index Scan using pk_serials on serials s
>>                           (cost=0.00..3.51 rows=1 width=4)
>>                   Index Cond: (s.serial_id = "outer".serial_id)
>>                   Filter: ((article_no = $0) AND (delivery_id = $1))
>> ---------------------------------------------------------------
>>  in the EXPLAIN result.
>>  For those who wonder why I do this FROM (SELECT...). I was searching
>> for
>> a way to use the result of an subselect for multiple calculations in the
>> SELECT clause and return that calculation results as individual columns.
>>  I tested a bit further and found out that PG behaves the same in case q
>> is a view. This makes me wonder how efficient the optimizer can work
>> with views - or even worse - nested views.
>>  Tested and reproduced on PG 7.4.1 linux and 8.0.0 win32.
>>   Thanks in advance,
>> Hannes Dorbath
>