From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | 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 13:59:33 |
Message-ID: | CA+TgmoaBn4Xk6f_Lq93309Vpt1jTvb=QGaKXgB7qK-WwJC1-=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 2, 2018 at 7:23 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > That doesn't seem like an unreasonable argument. I'm not sure whether
> > the right threshold is 4 or something a little bigger, but I bet it's
> > not very large. It seems important to me that before anybody thinks
> > about committing this, we construct some kind of destruction case
> > where repeated scans of the whole table are triggered as frequently as
> > possible, and then run that test with varying thresholds.
>
> Why do you think repeated scans will be a destruction case when there
> is no FSM for a small table?
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-02 14:07:10 | Re: WIP: Avoid creation of the free space map for small tables |
Previous Message | Tomas Vondra | 2018-11-02 13:28:17 | Re: WIP Patch: Add a function that returns binary JSONB as a bytea |