Re: Query Optimizer Failure / Possible Bug

Mhh. I have no clue about the internals of PostgreSQL and query planing,
but to me as user this should really be a thing the optimizer has to
work out..

On 03.04.2005 10:01, PFC wrote:
>
> 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(at)theendofthetunnel(dot)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
>>
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>