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 |
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 |