Re: mosbench revisited

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: mosbench revisited
Date: 2011-08-10 22:01:55
Message-ID: 81hb5pkjsc.fsf@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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.

Now, it could be that the idea is only worth “the electrons it's written
on” if all the relation extensions are taken care of by a background
process...

> 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?

--
dim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Byrne 2011-08-10 22:17:24 Re: Possible Bug in pg_upgrade
Previous Message Simon Riggs 2011-08-10 21:29:22 Re: wal_sender_delay (WalSndDelay) has served its purpose