Thanks a lot Madusudanan, Igor, Lutz and Jeff for your suggestions.
What I can confirm is that the UNION ideas runs extremely fast (don't
have access to the db right now to test the subquery idea, but will
check next week as I travel right now). Thanks again! :)
I was wondering: would it be
On Thu, Sep 22, 2016 at 6:37 AM, Madusudanan.B.N
wrote:
> > However, this results in an awful slow plan (requiring to scan the
> complete big_table which obviously isn't optimal)
>
> You mean to say there is a sequential scan ? An explain would be helpful.
> Are there indexes on the provided wher
Mike Broers writes:
> This is 9.5, sorry I didnt mention that in the initial post.
Hmm, that's odd then.
> I am guessing the issue is that the secondary non-indexed criteria is a
> search through a jsonb column?
Doubt it; it should have considered the plan you are thinking of anyway.
Maybe it d
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Igor Neyman
Sent: Thursday, September 22, 2016 10:36 AM
To: Sven R. Kunze ; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Multiple-Table-Spanning Joins wi
-Original Message-
From: Igor Neyman
Sent: Thursday, September 22, 2016 10:33 AM
To: 'Sven R. Kunze' ; pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause
-Original Message-
From: pgsql-performance-ow...@postgresql.org
Igor Neyman writes:
> table_a is too small, just 50 records.
> Optimizer decided (correctly) that Seq Scan is cheaper than using an index.
Yeah. The given test case is quite useless for demonstrating that you
have a problem, since it's actually *faster* on 9.5 than 9.1.
What I suspect is happen
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Sven R. Kunze
Sent: Thursday, September 22, 2016 9:25 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Cla
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Knels, Udo
Sent: Thursday, September 22, 2016 8:40 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Problem with performance using query with unnest a
> However, this results in an awful slow plan (requiring to scan the
complete big_table which obviously isn't optimal)
You mean to say there is a sequential scan ? An explain would be helpful.
Are there indexes on the provided where clauses.
Postgres can do a Bitmap heap scan to combine indexes,
Hi pgsql-performance list,
what is the recommended way of doing **multiple-table-spanning joins
with ORs in the WHERE-clause**?
Until now, we've used the LEFT OUTER JOIN to filter big_table like so:
SELECT DISTINCT
FROM
"big_table"
LEFT OUTER JOIN "table_a" ON ("big_table"."id" =
Hi,
I tried the following on the upgraded database:
analyze schema_test.table_a;
But the result is the same.
https://explain.depesz.com/s/hsx5
"Sort (cost=5.94..6.01 rows=26 width=6) (actual time=0.199..0.200 rows=3
loops=1)"
" Sort Key: table_a.col0002"
" Sort Method: quicksort Memory: 2
11 matches
Mail list logo
