Re: WIP: Avoid creation of the free space map for small tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, John Naylor <jcnaylor(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Avoid creation of the free space map for small tables
Date: 2018-11-02 14:38:45
Message-ID: CA+TgmoYzg3zH-VdPAxT6SZGtz5P9TXU6kk58_z-0gQhoX_DUbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 2, 2018 at 10:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > That's not what I'm saying. If we don't have the FSM, we have to
> > check every page of the table. If there's a workload where that
> > happens a lot on a table that is just under the size threshold for
> > creating the FSM, then it's likely to be a worst case for this patch.
>
> Hmm, you're assuming something not in evidence: why would that be the
> algorithm?

I think it's in evidence, in the form of several messages mentioning a
flag called try_every_block.

Just checking the last page of the table doesn't sound like a good
idea to me. I think that will just lead to a lot of stupid bloat. It
seems likely that checking every page of the table is fine for npages
<= 3, and that would still be win in a very significant number of
cases, since lots of instances have many empty or tiny tables. I was
merely reacting to the suggestion that the approach should be used for
npages <= 32; that threshold sounds way too high.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-11-02 14:42:21 Re: PG vs macOS Mojave
Previous Message Tom Lane 2018-11-02 14:35:12 Re: Vacuum Full does not release the disk size space after delete from table