From: | Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com> |
---|---|
To: | Shrikant Bhende <shrikantpostgresql(at)gmail(dot)com> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Join for the parent table will not leverage the index scan |
Date: | 2021-08-13 15:50:06 |
Message-ID: | CAM+6J95KoHhtSZgqO9JLnFcC4OVwaTPTyxt1EVda5u7FFhw2kA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
On Fri, 13 Aug 2021 at 17:54, Shrikant Bhende <shrikantpostgresql(at)gmail(dot)com>
wrote:
>
>
> The only place an index scan is used is to filter down page_details. In my
> second query,
> when explicitly joining single partitions an index scan is used to perform
> filtering, and the join as well:
>
>
can you share the results of explain via New explain | explain.depesz.com
<https://explain.depesz.com/>
explain analyze <query>
set enable_seqscan TO off;
explain analyze <query>
maybe the planner seems to find seq scans faster than index scans.
The plan used by the optimizer should help understand the decision.
Also, I assume the tables were analyzed too.
If not, please run analyze on the tables.
also what do you see with enable_partitionwise_join enabled
set enable_partitionwise_join to on;
explain analyze <query>
set enable_seqscan TO off;
explain analyze <query>
--
Thanks,
Vijay
Mumbai, India
From | Date | Subject | |
---|---|---|---|
Next Message | Shrikant Bhende | 2021-08-14 16:31:29 | Join for the parent table will not leverage the index scan |
Previous Message | Shrikant Bhende | 2021-08-13 12:23:39 | Join for the parent table will not leverage the index scan |
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2021-08-13 16:16:07 | Re: Multiple Postgres process are running in background |
Previous Message | Michael Lewis | 2021-08-13 15:37:22 | Re: Partitioning a table by integer value (preferably in place) |