Mathieu De Zutter writes:
The problem is that this join is performing very badly when more than one
work is involved. It chooses a plan that is orders of magnitude slower.
I have attached
- The (simplified) table definitions
- The (simplified) view
- Two queries with explain analyze plan: "IN (1)" => fast, "IN (1,3)" =>
- postgresql.conf
The reason you get a nice plan in the first case is that " in (1)"
is treated as " = 1", and then there is logic that combines that with
" =" to conclude that we can synthesize a condition " = 1".
None of that happens when there's more than one IN item, because it's not
an equality operator anymore.

You might be able to do something like
     JOIN (VALUES (1),(3)) foo(x) ON = foo.x

    regards, tom lane

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
grouppgsql-performance @
postedAug 30, '13 at 9:06a
activeAug 30, '13 at 2:01p

2 users in discussion

Tom Lane: 1 post Mathieu De Zutter: 1 post



site design / logo © 2018 Grokbase