On Thu, Dec 17, 2009 at 9:15 PM, Robert Haas <robertmhaas@gmail.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
