Re: patch - per-tablespace random_page_cost/seq_page_cost
От | Robert Haas |
---|---|
Тема | Re: patch - per-tablespace random_page_cost/seq_page_cost |
Дата | |
Msg-id | 603c8f070912272352r6e17503cl3fd0e01f22f03d78@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch - per-tablespace random_page_cost/seq_page_cost (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: patch - per-tablespace random_page_cost/seq_page_cost
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: