On Fri, Nov 2, 2018 at 7:37 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.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. >
In the past, you seem to have suggested an approach to try each block [1] for small tables which don't have FSM. I think if we do what you are suggesting now, then we don't need to worry much about any regression and code will be somewhat simpler, but OTOH, I don't see much harm in trying every block if we keep the threshold as no more than 4. That would address more cases. [1] - https://www.postgresql.org/message-id/11360.1345502641%40sss.pgh.pa.us -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
