Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Philip Semanchuk <philip(at)americanefficient(dot)com>
Cc: Pavlos Kallis <pkallis(at)yourhero(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it
Date: 2024-01-30 20:38:36
Message-ID: CAApHDvqsOy=LxcrejJ_fdQn7LZ=D3RginnWzMvhK+6jej6z39g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 31 Jan 2024 at 09:09, Philip Semanchuk
<philip(at)americanefficient(dot)com> wrote:
> So in your case those 5m rows that you deleted were probably still clogging up your table until you ran VACUUM FULL.

It seems more likely to me that the VACUUM removed the rows and just
left empty pages in the table. Since there's no index on expires_at,
the only way to answer that query is to Seq Scan and Seq Scan will
need to process those empty pages. While that processing is very fast
if the page's item pointers array is empty, it could still be slow if
the page needs to be read from disk. Laurenz's request for the explain
(analyze, buffers) output with track_io_timing on will help confirm
this.

If it is just reading empty pages that's causing this issue then
adding that missing index would improve the situation after running
just plain VACUUM each time there's a bulk delete.

David

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mehmet COKCEVIK 2024-01-31 11:18:23 Performance
Previous Message Philip Semanchuk 2024-01-30 20:08:40 Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it