From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Paul Schaap <ps(at)ipggroup(dot)com> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Postgres 11.0 Partitioned Table Query Performance |
Date: | 2018-11-08 03:32:30 |
Message-ID: | CAKJS1f-ouzOq2KDSYiSxqWHiVN29i-Oq9vpcjM=d7DOP4ztUkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 8 November 2018 at 15:28, Paul Schaap <ps(at)ipggroup(dot)com> wrote:
> I have an issue, and a partial workaround, with a query outlined below. What
> I am hoping to get to is a Parallel Index Only Scan on my partition indexes
> as theoretically that should be the fastest, but can only get either a
> Parallel Seq Scan on each partition which is very slow, or a non parallel
> Index Only Scan which is faster.
>
> If I express my query this way:
>
> EXPLAIN SELECT trl.*, tr.trans_id
> FROM transactions_raw_load trl
> LEFT OUTER JOIN transactions_raw tr ON tr.trans_id = trl.trans_id;
>
> Note there is an index on tr.trans_id, and no indexes on
> transactions_raw_load.
>
> I get the following poor performing query plan (I got bored and gave up
> after an hour):
Parallel nodes cannot be on the inside of a nested loop join, and
you've mentioned that the other table has no indexes so I guess you
didn't mean on the outside.
You may find that a serial nested loop plan with a parameterised inner
index only scan to be faster than the hash join. If you're finding
that subquery scan is better, then you may want to consider dropping
random_page_cost a bit or increasing effective_cache_size. This will
lower the estimated cost of random IO for indexes scans.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-11-08 05:48:01 | Re: Largest & Smallest Functions |
Previous Message | Paul Schaap | 2018-11-08 02:28:05 | Postgres 11.0 Partitioned Table Query Performance |