From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
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:07:10 |
Message-ID: | 16879.1541167630@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? On a FSM-less table, I'd be inclined to just check the
last page and then grow the table if the tuple doesn't fit there.
This would, in many cases, soon result in a FSM being created, but
I think that's just fine. The point of the change is to optimize
for cases where a table *never* gets more than a few inserts. Not, IMO,
for cases where a table gets a lot of churn but never has a whole lot of
live tuples. In the latter scenario we are far better off having a FSM.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2018-11-02 14:21:32 | Re: COPY FROM WHEN condition |
Previous Message | Robert Haas | 2018-11-02 13:59:33 | Re: WIP: Avoid creation of the free space map for small tables |