Re: Postgres 11.0 Partitioned Table Query Performance
От | David Rowley |
---|---|
Тема | Re: Postgres 11.0 Partitioned Table Query Performance |
Дата | |
Msg-id | CAKJS1f-ouzOq2KDSYiSxqWHiVN29i-Oq9vpcjM=d7DOP4ztUkg@mail.gmail.com обсуждение исходный текст |
Ответ на | Postgres 11.0 Partitioned Table Query Performance (Paul Schaap <ps@ipggroup.com>) |
Список | pgsql-general |
On 8 November 2018 at 15:28, Paul Schaap <ps@ipggroup.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
В списке pgsql-general по дате отправления: