| 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: | Whole Thread | Raw Message | 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) |