Benjamin Coutu writes:
> Please consider the following three semantically equivalent, but differently
> written queries:
> ...
> Queries A + B generate the same plan and execute as follows:
> -> Finalize HashAggregate (cost=32879.78..33102.62 rows=22285
> width=12) (actual time=450.72
There is actually another separate issue here apart from that the planner
obviously choosing the wrong plan as originally described in my last message, a
plan it knows to be more expensive based on cost estimates.
Take a look at the way the filter condition is treated differently when
estimatin
dth=332) (actual time=0.003..0.003 rows=1 loops=15521)
Index Cond: ("ID" = c.item)
Planning time: 0.223 ms
Execution time: 526.203 ms
== Original ==
From: David Rowley
To: Benjamin Coutu
Date: Sun, 29 Oct 2017 12:46:42 +0100
Subject: Re: [PERFORM] Cheaper s
On 30 October 2017 at 00:24, Benjamin Coutu wrote:
> -> Index Scan using "PK_items_ID" on items a (cost=0.42..1.05 rows=1
> width=332) (actual time=0.003..0.003 rows=1 loops=15521 total=46.563)
I've never seen EXPLAIN output like that before.
Is this some modified version of PostgreSQL?
--
Hello everyone,
Please consider the following three semantically equivalent, but differently
written queries:
Query A:
SELECT * FROM items a INNER JOIN (
SELECT item, sum(amount) stock FROM stocktransactions GROUP BY item HAVING
sum(amount) >= 1
) b ON b.item = a. "ID"
Query B:
SELECT * FR
