Robert Haas escribió:
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com writes:
Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu 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
Robert Haas escribió:
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Tue, Nov 3, 2009 at 7:44 AM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit :
We could have a column for all booleans, a column for all integers,
etc. but that's not really any more
On Tue, Nov 3, 2009 at 7:51 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this is the case, then I think we could just decide that their name
is reloptions due to hysterical
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
Hi, excuse the quoting style... and the intrepid nature of the
following content...
--
dim
Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu 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
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 something
On Mon, Nov 2, 2009 at 4:11 PM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Hi, excuse the quoting style... and the intrepid nature of the following
content...
--
dim
Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit :
We could have a column for all booleans, a column for all
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas robertmh...@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
On Nov 1, 2009, at 7:43 AM, Greg Stark gsst...@mit.edu wrote:
On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas robertmh...@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
On Tue, Oct 27, 2009 at 9:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Alvaro Herrera escreveu:
Tom Lane escribió:
Greg Stark gsst...@mit.edu 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
On Mon, Oct 26, 2009 at 11:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de 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
Robert Haas robertmh...@gmail.com 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
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
David Fetter escribió:
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Oct 27, 2009 at 9:20 PM, David Fetter da...@fetter.org wrote:
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Oct 27, 2009 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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,
On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas robertmh...@gmail.com 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
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
On Mon, Oct 26, 2009 at 3:05 PM, Josh Berkus j...@agliodbs.com 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
Greg Stark gsst...@mit.edu 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.
Hi,
On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
Greg Stark gsst...@mit.edu 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.
Tom Lane escribió:
Greg Stark gsst...@mit.edu 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
Andres Freund and...@anarazel.de 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
On Mon, Oct 19, 2009 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us 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)
30 matches
Mail list logo
