Re: mosbench revisited

Excerpts from Robert Haas's message of mié ago 10 21:27:08 -0400 2011:
> 2011/8/10 Dimitri Fontaine <dfontaine@hi-media.com>:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> However, it doesn't really do anything to solve this problem.  The
> >> problem here is not that the size of the relation is changing too
> >> frequently - indeed, it's not changing at all in this test case.  The
> >> problem is rather that testing whether or not the size has in fact
> >> changed is costing too much.
> >
> > You were complaining about the cost of the cache maintenance, that in
> > the current scheme of things would have to be called far too often.
> > Reducing the relation extension trafic would allow, I guess, to have
> > something more expensive to reset the cache -- it would not happen much.
> 
> That's an interesting point.  I confess to having no idea how frequent
> relation extension is now, or how much overhead we could add before it
> started to get noticeable.

I have seen several cases on which it (rel extension) is really
troublesome.  Think insertion on large bytea fields -- the toast table's
extension lock was heavily contended.  When this was in 8.1 we had quite
some trouble because of the locking involving some shared buffer pool
lwlock which is fortunately now partitioned; even without that, it is a
major contention point.  These were insert-only tables, so pages are
always full except the last one.

> >> The reason why we are testing the size of the relation here rather
> >> than just using reltuples is because the relation might have been
> >> extended since it was last analyzed.  We can't count on analyze to run
> >> often enough to avoid looking at the actual file size.  If the file's
> >> grown, we have to scale the number of tuples up proportional to the
> >> growth in relpages.
> >
> > Could we send the same message to the stat collector as autoanalyze is
> > doing each time we extend a relation?
> 
> Mmm, maybe.  I don't really like the idea of getting the stats
> collector involved in this; that seems like it will likely add
> complexity without any corresponding benefit.

Yeah, it adds delay and uncertainty (UDP being lossy).

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support