Re: per-tablespace random_page_cost/seq_page_cost
От | Robert Haas |
---|---|
Тема | Re: per-tablespace random_page_cost/seq_page_cost |
Дата | |
Msg-id | 5A5FAFBC-6C30-450B-882A-9FD961AEC1E0@gmail.com обсуждение исходный текст |
Ответ на | Re: per-tablespace random_page_cost/seq_page_cost (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
On Nov 1, 2009, at 7:43 AM, Greg Stark <gsstark@mit.edu> wrote: > On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas <robertmhaas@gmail.com> > wrote: >> Looking at this a little more, it seems that part of the motivation >> for the existing design is that user-created AMs might require >> arbitrary options, which therefore can't be wired into the system >> catalogs. There's no equivalent for tablespaces (we could add one >> some day, I suppose), so there's less intrinsic reason to think we >> have to do it that way. > > Can't custom modules define arbitrary options which they declare can > be defined per tablespace? Yeah, probably we can support that for free, although I'm not sure there is much demand for it. > We could have a column for all booleans, a column for all integers, > etc. but that's not really any more normalized than having a single > - how to marshal each value > type. That has no advantages and several disadvantages AFAICS. I don't want to get sidetracked here. The real issue is the one I discussed in the portion of the email you didn't quote... ...Robert
В списке pgsql-hackers по дате отправления: