Re: patch - per-tablespace random_page_cost/seq_page_cost

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost
Date: 2009-12-28 07:52:46
Message-ID: 603c8f070912272352r6e17503cl3fd0e01f22f03d78@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 17, 2009 at 9:15 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Going once...  going twice...  since no one has suggested anything or
> spoken against the proposal above, I'm just going to implement
> seq_page_cost and random_page_cost for now.
[...]
> Per the email that I just sent a few minutes ago, there doesn't appear
> to be a performance impact in doing this even in a relatively stupid
> way - every call that requires seq_page_cost and/or random_page_cost
> results in a syscache lookup and then uses the relcache machinery to
> parse the returned array.
>
> That leaves the question of what the most elegant design is here.  Tom
> suggested upthread that we should tag every RelOptInfo - and,
> presumably, IndexOptInfo, though it wasn't discussed - with this
> information.  I don't however much like the idea of adding identically
> named members in both places.  Should the number of options expand in
> the future, this will become silly very quickly.  One option is to
> define a struct with seq_page_cost and random_page_cost that is then
> included in RelOptInfo and IndexOptInfo.  It would seem to make sense
> to make the struct, rather than a pointer to the struct, the member,
> because it makes the copyfuncs/equalfuncs stuff easier to handle, and
> there's not really any benefit in incurring more palloc overhead.
>
> However, I'm sort of inclined to go ahead and invent a mini-cache for
> tablespaces.  It avoids the (apparently insignificant) overhead of
> reparsing the array multiple times, but it also avoids bloating
> RelOptInfo and IndexOptInfo with more members than really necessary.
> It seems like a good idea to add one member to those structures
> anyway, for reltablespace, but copying all the values into every one
> we create just seems silly.  Admittedly there are only two values
> right now, but again we may want to add more someday, and caching at
> the tablespace level just seems like the right way to do it.
>
> Thoughts?

Hearing no thoughts, I have implemented as per the above. PFA the
latest version. Any reviews, comments, feedback, etc. much
appreciated.

Thanks,

...Robert

Attachment Content-Type Size
spcoptions-v3.patch text/x-patch 49.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-12-28 07:59:01 Re: info about patch: using parametrised query in psql
Previous Message Robert Haas 2009-12-28 07:11:23 Re: Removing pg_migrator limitations