Re: What popular, large commercial websites run

Shaun Thomas <sthomas@townnews.com> writes:
> Either way, having such a lookup before every insert/update doesn't seem
> terribly efficient.  It seems like this would displace the slowdown
> caused by vacuum to inserts and updates.

Actually, I believe not.  With the old scheme, the last page of an
active table was a hot-spot for contention, because every insert/update
on the table had to get an exclusive lock on that page.  With the new
scheme, different backends can be inserting tuples into different pages
concurrently.  (And yes, the FSM is designed to favor that happening;
if multiple pages are recorded as having free space, different backends
will get pointed to different pages to do insertions in.)

The in-memory FSM could itself become a hot-spot for contention, but
the profiles that I've been able to take do not show any indication
that that's a problem in practice.  Any given backend will touch the
FSM only when it's exhausted the free space in its current target
insert page, so the traffic to the FSM is significantly less than the
total insertion traffic.

Also, to the extent that this approach keeps the total table size
constant, we avoid a lot of OS-level overhead for repeated extensions
of the disk file.

So I have no reason to think that insert/update is measurably slower
in this scheme than before, and some reasons to think it may often be
faster.  I have not tried to benchmark the speed of insert/update taken
in isolation, though.

> But It's also why I consider MVCC
> fundamentally flawed.  If Postgres used rollback segments like Oracle,
> DB2 or other mainstream RDBMS's, this wouldn't be an issue; only locked
> rows are put in the rollback segment, so the versioning is still
> available, and it would clean up after itself on commit or rollback.

I do not agree with this reasoning, and I do *not* see that rollback
segments have any advantages over our approach.

            regards, tom lane