On Tue, Nov 3, 2009 at 7:51 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
>> wrote:
>> >> > If this is the case, then I think we could just decide that their name
>> >> > is reloptions due to hysterical reasons and be done with it.
>> >>
>> >>
On Tue, Nov 3, 2009 at 7:44 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>>> Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
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
column for al
Robert Haas escribió:
> On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
> wrote:
> >> > If this is the case, then I think we could just decide that their name
> >> > is reloptions due to hysterical reasons and be done with it.
> >>
> >> Yeah. It's particularly unfortunate that we call them "relopt
Robert Haas writes:
>> Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
>>>
>>> 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
>>> column for all the types with a rule for how to marshal each value
>>> type.
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
wrote:
>> > If this is the case, then I think we could just decide that their name
>> > is reloptions due to hysterical reasons and be done with it.
>>
>> Yeah. It's particularly unfortunate that we call them "reloptions" in
>> the code but "storage
Robert Haas escribió:
> On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >
> >> I don't see anything in this code that is very rel-specific, so I
> >> think it would be possible to implement spcoptions by just defining
> >> RELOPT_KIND_TABLESPACE and ignoring th
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> I don't see anything in this code that is very rel-specific, so I
>> think it would be possible to implement spcoptions by just defining
>> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of
>> a
On Mon, Nov 2, 2009 at 4:11 PM, Dimitri Fontaine wrote:
> Hi, excuse the quoting style... and the intrepid nature of the following
> content...
>
> --
> dim
>
> Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
>>
>> We could have a column for all booleans, a column for all integers,
>> etc. but that'
Dimitri Fontaine escribió:
> Thé other day, on IRC, someone wanted a dynamic table accepting
> value in whichever column you name. That would probably mean having
> a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you.
That sounds more like something you'd do with hstore or somethin
Hi, excuse the quoting style... and the intrepid nature of the
following content...
--
dim
Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
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
column for all the t
Robert Haas escribió:
> I don't see anything in this code that is very rel-specific, so I
> think it would be possible to implement spcoptions by just defining
> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of
> an unsavory feeling that I'm sure someone is going to complain a
On Nov 1, 2009, at 7:43 AM, Greg Stark wrote:
On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas
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 syst
On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas 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 tabl
On Tue, Oct 27, 2009 at 9:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> I confess that I'm a bit mystified about the design of the reloptions
>> stuff. It seems kind of odd to store structured data as text[]; it's
>> kind of the opposite of what I would normally recommend as good
>> database de
On Tue, Oct 27, 2009 at 10:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> For things like autovacuum options, the actual representation probably
>> doesn't matter much because I'm guessing that the amount of work being
>> done by vacuum dwarfs the parsing cost, and it's a background task
>> anyw
Robert Haas writes:
> For things like autovacuum options, the actual representation probably
> doesn't matter much because I'm guessing that the amount of work being
> done by vacuum dwarfs the parsing cost, and it's a background task
> anyway. But this seems like a less solid argument for things
On Tue, Oct 27, 2009 at 9:20 PM, David Fetter wrote:
> On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > I confess that I'm a bit mystified about the design of the
>> > reloptions stuff. It seems kind of odd to store structured data as
>> > text[]; it's kind of
David Fetter escribió:
> On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > I confess that I'm a bit mystified about the design of the
> > > reloptions stuff. It seems kind of odd to store structured data as
> > > text[]; it's kind of the opposite of what I wou
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > I confess that I'm a bit mystified about the design of the
> > reloptions stuff. It seems kind of odd to store structured data as
> > text[]; it's kind of the opposite of what I would normally
> > recommend as good
Robert Haas writes:
> I confess that I'm a bit mystified about the design of the reloptions
> stuff. It seems kind of odd to store structured data as text[]; it's
> kind of the opposite of what I would normally recommend as good
> database design.
It's definitely a bit EAV-ish :-(. But I don't s
On Mon, Oct 26, 2009 at 11:07 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
>>> I think a design that is limited to a prespecified set of GUCs is
>>> broken by definition. It'd be better to make it work like
>>> ALTER DATABASE SET.
>
>> How sh
Alvaro Herrera escreveu:
> Tom Lane escribió:
>> Greg Stark writes:
>>> Still far from convinced on that one. But effective_io_concurrency
>>> should be included even in the first pass.
>> I think a design that is limited to a prespecified set of GUCs is
>> broken by definition. It'd be better to
Andres Freund writes:
> On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
>> I think a design that is limited to a prespecified set of GUCs is
>> broken by definition. It'd be better to make it work like
>> ALTER DATABASE SET.
> How should that work if there are conflicting settings in two tab
Tom Lane escribió:
> Greg Stark writes:
> > Still far from convinced on that one. But effective_io_concurrency
> > should be included even in the first pass.
>
> I think a design that is limited to a prespecified set of GUCs is
> broken by definition. It'd be better to make it work like
> ALTER
Hi,
On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
> Greg Stark writes:
> > Still far from convinced on that one. But effective_io_concurrency
> > should be included even in the first pass.
> I think a design that is limited to a prespecified set of GUCs is
> broken by definition. It'd be b
Greg Stark writes:
> Still far from convinced on that one. But effective_io_concurrency
> should be included even in the first pass.
I think a design that is limited to a prespecified set of GUCs is
broken by definition. It'd be better to make it work like
ALTER DATABASE SET.
On Mon, Oct 26, 2009 at 3:05 PM, Josh Berkus wrote:
> I'm thinking an array, in case we want to make other tablespace cost
> parameters in the future.* Or, better, whatever structure we're
> currently using for ROLEs.
>
> (* for example, if someone does manage a filesystem with a separate
> cache
Robert,
> As to (1), my thought is to add two new float8 columns to
> pg_tablespace. The naming is a little awkward, because
> random_page_cost and seq_page_cost would not fit with our (rather odd)
> convention for naming system catalog columns. I'm tempted to call
> them spcrandompagecost and s
On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas wrote:
> Arguably, you would expect parameters set using this syntax to be
> stored similar to reloptions - that is, as text[]. But as we're going
> to need these values multiple times per table to plan any non-trivial
> query, I don't want to inject u
On Mon, Oct 19, 2009 at 6:33 PM, Tom Lane wrote:
> Per-table is not physically sensible. Per-tablespace has some rationale
> to it.
I took a look at this and it seems fairly straightforward. It
basically requires (1) deciding where and how to store per-tablespace
defaults, (2) making those def
30 matches
Mail list logo
