Re: Query Optimizer Failure / Possible Bug

From: PFC <lists(at)boutiquenumerique(dot)com>
To: "Hannes Dorbath" <light(at)theendofthetunnel(dot)de>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Query Optimizer Failure / Possible Bug
Date: 2005-04-03 08:01:13
Message-ID: op.sonckb1pth1vuj@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

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

In response to


Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2005-04-03 12:18:20 Re: Delete query takes exorbitant amount of time
Previous Message Will LaShell 2005-04-02 16:21:36 Re: Follow-Up: How to improve db performance with $7K?