Skip site navigation (1) Skip section navigation (2)

Query Optimizer Failure / Possible Bug

From: Hannes Dorbath <light(at)theendofthetunnel(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Subject: Query Optimizer Failure / Possible Bug
Date: 2005-03-24 10:31:11
Message-ID: d1u4m3$1qm2$ (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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


pgsql-performance by date

Next:From: Rick JansenDate: 2005-03-24 10:41:04
Subject: Re: Tsearch2 performance on big database
Previous:From: Patrick VedrinesDate: 2005-03-24 10:08:55
Subject: Re: CPU 0.1% IOWAIT 99% for decisonnal queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group