Re: per-tablespace random_page_cost/seq_page_cost

On Tue, Oct 27, 2009 at 10:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> For things like autovacuum options, the actual representation probably
>> doesn't matter much because I'm guessing that the amount of work being
>> done by vacuum dwarfs the parsing cost, and it's a background task
>> anyway.  But this seems like a less solid argument for things like
>> fillfactor and the proposed per-tablespace
>> seq_page_cost/random_page_cost, which will be accessed by many queries
>> and in the latter case often more than once.  Ideally (or so it seems
>> to me) you'd like to fetch those things out of Form_pg_whatever rather
>> than parsing text strings to get at 'em.
>
> I think efficiency arguments here are hogwash.  In the first place,
> we'd certainly cache the results someplace (relcache or something like
> it) if retrieve performance seems to be a bottleneck at all.  In the
> second place, composite types are so hugely inefficient as to swamp any
> gain you'd get from the columns being the right type once you got at
> them.  (atoi and friends are cheap by comparison.)

We must be talking about different things, because I can't believe
this is true of what I'm thinking about. I'm not suggesting having a
column called reloptions of composite type; I'm suggesting that an
option like fillfactor would have its very own table column, just like
relpages or relhasindex. Surely that's gotta be faster than text; it
overlays onto a C struct, which is about as fast as it gets.

I agree that caching mitigates many of the problems with this from an
efficiency standpoint, possibly to the point where it isn't worth
caring about. But it does seem grotty, and I feel like it has to cost
something: we read in an array of text[] and convert it to a C struct,
which is exactly the form it would already be in if we just made it
part of Form_pg_class in the first place. The only way I can think
that the current representation could be faster is that when there are
NO reloptions at all, the parsing step can be skipped, and yet overall
Form_pg_class is smaller than it would be otherwise, which is of some
miniscule benefit.

> It's possible that changing this is worthwhile on logical cleanliness
> grounds; but I think it will be a net loss in efficiency, and definitely
> a net loss in terms of code complexity at the C level.

One of my concerns about the current representation is that it doesn't
seem easily generalizable to objects that are not in pg_class, such as
tablespaces. I fear that supporting spcoptions as text[] along the
lines of reloptions will require quite a bit of refactoring to avoid
code duplication, whereas adding a few new columns to pg_tablespace
and maybe making a syscache for it looks pretty simple. On the other
hand, that would leave us with completely different representations
for essentially the same sort of data, which isn't particularly
appealing either.

...Robert