From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | jcnaylor(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Avoid creation of the free space map for small tables |
Date: | 2018-11-02 11:22:58 |
Message-ID: | CAA4eK1LeMSwYk1Xj3WPrAW=c7QyC4uJ1rJKzzw_=ezPQTfz_tQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 31, 2018 at 10:29 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Oct 23, 2018 at 9:42 AM John Naylor <jcnaylor(at)gmail(dot)com> wrote:
> > A case could be made for setting the threshold to 4, since not having
> > 3 blocks of FSM in shared buffers exactly makes up for the 3 other
> > blocks of heap that are checked when free space runs out.
>
> 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?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Surafel Temesgen | 2018-11-02 11:23:19 | Re: COPY FROM WHEN condition |
Previous Message | Amit Kapila | 2018-11-02 11:12:29 | Re: zheap: a new storage format for PostgreSQL |