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
It's not a modified postgres version. It's simply for my convenience that my
tooling calculats "total" as "actual time" multiplied by "loops". Looks like I
didn't properly strip that away when copy-pasting.
Here are the queries and original plans again, sorry for the confusion.
Query A:
SELECT
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
