patch - per-tablespace random_page_cost/seq_page_cost
in [PgSql]
|
From: Robert Haas on 4 Jan 2010 13:55 On Mon, Jan 4, 2010 at 10:42 AM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Robert Haas escribió: > >> Hmm, I see this needs to be rebased over Tom's latest changes, but the >> conflict I got was in syscache.h, rather than syscache.c. Not sure if >> that's what you were going for or if there's another issue. Updated >> patch attached. > > FWIW I think the reloptions code in this patch is sane enough. The fact > that it was this easily written means that the API for reloptions was > reasonably chosen, thanks :-) :-) Actually, there are some things about it that I'm not entirely happy with, but I haven't brought them up because I don't have a clear idea what I think we should do about them. The special-case hack to handle the "oids" option is one of them.... another, possibly related, is that I wish we could decouple the options-validation logic from the backend storage representation. But those are issues for a future thread. I do think it's pretty well-done overall. > Hmm, it seems we're missing a "need_initialization = false" at the > bottom of initialize_reloptions ... I'm wondering what happened to > that?? It appears that it has never been there. $ git log -Sneed_initialization master src/backend/access/common/reloptions..c commit f35e4442a6c9893e72fe870d9e1756262d542027 Author: Alvaro Herrera <alvherre(a)alvh.no-ip.org> Date: Mon Jan 5 17:14:28 2009 +0000 Change the reloptions machinery to use a table-based parser, and provide a more complete framework for writing custom option processing routines by user-defined access methods. Catalog version bumped due to the general API changes, which are going to affect user-defined "amoptions" routines. That was the original patch that added need_initialization, and it didn't add that line. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 4 Jan 2010 14:07 On Sun, Jan 3, 2010 at 11:19 PM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > >> --- 49,63 ---- >> * ---------------- >> */ >> >> ! #define Natts_pg_tablespace 6 > > Should be 5? Yep. I also fixed the other two bits of brain fade that you pointed out to me via private email. Updated patch attached. ....Robert
From: Robert Haas on 4 Jan 2010 14:17 On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> My only objection to that is that if we're going to add attoptions >> also, I'd like to get this committed first before I start working on >> that, and we're running short on time. If you can commit his patch in >> the next day or two, then I am fine with rebasing mine afterwards, but >> if it needs more work than that then I would prefer to commit mine so >> I can move on. Is that reasonable? > > Fair enough --- if I can't get it done today I will let you know and > hold off. OK. I just took a really fast look at that the bki patch and it looks pretty nice, so I hope you're able to get it in. Of course, I'm biased because it's based on earlier work of my own, but biased != wrong. :-) A lot more work will need to be done to escape the insanity that is our current method of handling system catalogs, but this seems like a good step in the right direction. I also observe that it applies cleanly over my current spcoptions branch, so the merge conflicts might be a non-issue. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: John Naylor on 4 Jan 2010 19:30 Tom, It seems I introduced a couple errors in src/tools/msvc/clean.bat in the bki patch. I'm attaching a cumulative fix. I can resend the complete updated patch, if you like... Sorry! :-) John > I'm planning to go look at Naylor's bki refactoring patch now. Assuming > there isn't any showstopper problem with that, do you object to it > getting committed first? Either order is going to create a merge > problem, but it seems like we'd be best off to get Naylor's patch in > so people can resync affected patches before the January commitfest > starts.
From: Robert Haas on 5 Jan 2010 10:17
On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> My only objection to that is that if we're going to add attoptions >> also, I'd like to get this committed first before I start working on >> that, and we're running short on time. If you can commit his patch in >> the next day or two, then I am fine with rebasing mine afterwards, but >> if it needs more work than that then I would prefer to commit mine so >> I can move on. Is that reasonable? > > Fair enough --- if I can't get it done today I will let you know and > hold off. OK, so since you got this done, I'm going to go ahead and rebase & commit mine today, after a final read-through or two, unless you or anyone else wants to insert some last-minute objections? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |