| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Wells Oliver <wells(dot)oliver(at)gmail(dot)com> |
| Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Poor performance due to parallel seq scan on indexed date field |
| Date: | 2023-06-21 20:54:51 |
| Message-ID: | CAMkU=1xi=reF19MUrU=1uOFCd4cwU5Suc1yyisfxC=+A8Xgsuw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Wed, Jun 21, 2023 at 2:32 PM Wells Oliver <wells(dot)oliver(at)gmail(dot)com> wrote:
> Dead simple date scan across a big-ish table (est. 23,153,666 rows)
>
Simple, but massive.
You should turn on track_io_timing (if it is not already) and then do
EXPLAIN (ANALYZE, BUFFERS)
You haven't shown that poor performance is due to the parallel seq scan,
only that one particular plan happens to have both of those features at the
same time. If you disable parallel queries
(max_parallel_workers_per_gather=0), what plan do you get instead and how
long does it take? What if you turn off enable_seqscan altogether?
Cheers,
Jeff
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2023-06-21 21:03:41 | Re: Poor performance due to parallel seq scan on indexed date field |
| Previous Message | kyle Hailey | 2023-06-21 20:22:43 | Re: AWS RDS "sessions" and pg_stat_activity |