Re: patch - per-tablespace random_page_cost/seq_page_cost

On Sat, Nov 14, 2009 at 4:58 PM, Tom Lane  wrote:
> I don't think there's even a
> solid consensus right now on which GUCs people would want to set at the
> tablespace level.

This seems like an important point that we need to nail down.  The
original motivation for this patch was based on seq_page_cost and
random_page_cost, to cover the case where, for example, one tablespace
is on an SSD and another tablespace is on a RAID array.

Greg Stark proposed adding effective_io_concurrency, and that makes
plenty of sense to me, but I'm sort of disinclined to attempt to
implement that as part of this patch because I have no familiarity
with that part of the code and no hardware that I can use to test
either the current behavior or the modified behavior.  Since I'm
recoding this to use the reloptions mechanism, a patch to add support
for that should be pretty easy to write as a follow-on patch once this
goes in.

Any other suggestions?

Current version of patch is attached.  I've revised it to use the
reloptions stuff, but I don't think it's committable as-is because it
currently thinks that extracting options from a pg_tablespace tuple is
a cheap operation, which was true in the non-reloptions-based
implementation but is less true now.  At least, some benchmarking
needs to be done to figure out whether and to what extent this is an
issue.

...Robert