| From: | Justin <zzzzz(dot)graf(at)gmail(dot)com> |
|---|---|
| To: | Sreejith P <sreejith(at)lifetrenz(dot)com> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Suddenly all queries moved to seq scan |
| Date: | 2024-11-20 17:28:15 |
| Message-ID: | CALL-XeNFLbEE8=__jL-SvN2C7+VbZ1YOjr2krD+QwCY6k_we3w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Nov 20, 2024 at 9:09 AM Sreejith P <sreejith(at)lifetrenz(dot)com> wrote:
>
>
>
> Queries were taking 20 ms started taking 60 seconds. So have done SQL
> analyse to understand about query plan. There we found that query planner
> taking seq scan instead in index scan.
>
> I would like to add one ore point. A delete query were running in DB from
> 2 days for deleting around 80 million records.
This can cause this specific problem where the number of dead tuples and
lack of autovacuum running can cause the statistics to favor a sequential
scan over an index scan. Taking into account the length of time the delete
took it would hold a number of datapages and tuples in a lock state, which
can lead to blocking queries and prevent autovacuum/analyze.
It is best to do bulk deletes in batches and have a rest period between
batches to allow autovacuum and analyze to keep up.. Doing deletes in
batches reduces the number of resources being consumed.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Istvan Soos | 2024-11-20 18:04:44 | A table lock inside a transaction depends on query protocol being used? |
| Previous Message | Adrian Klaver | 2024-11-20 17:15:42 | Re: Postgres service not starting on windows after install if not installed into standard locations |