Amit Kapila writes:
> Another point to think in this regard is what if tomorrow somebody
> requests something similar for Create Materialized View? Isn't it
> better to introduce a GUC default_tablespace_parent or
> default_parent_tablespace?
That's exactly what I have in mind :)
--
Sent via
On Mon, Nov 28, 2016 at 6:19 PM, Amit Kapila wrote:
> On Sat, Nov 26, 2016 at 9:46 PM, Tom Lane wrote:
>>
>> If we just did points 1 and 2 then a bool GUC would suffice. I'm
>> not sure how to handle all three cases cleanly. We could define
>> default_index_tablespace as empty to get point 1 or
On Sat, Nov 26, 2016 at 9:46 PM, Tom Lane wrote:
> Amit Kapila writes:
>> What will such a storage parameter (default_tablespace) mean at table
>> level and how it will different from existing default_tablespace? I
>> think the usage asked by Amos is quite genuine, but not sure if
>> introducing
Jim Nasby writes:
> On 11/27/16 2:01 AM, Amos Bird wrote:
>>
>>> I was thinking about introducing a new GUC, named something like
>>> default_index_tablespace, which would need to have at least these
>>> behaviors:
>>
>> Should we also consider the chidren tables as mentioned by Corey?
>
> Wouldn
On 11/27/16 2:01 AM, Amos Bird wrote:
I was thinking about introducing a new GUC, named something like
default_index_tablespace, which would need to have at least these
behaviors:
Should we also consider the chidren tables as mentioned by Corey?
Wouldn't point #2 handle that?
2. index tab
On Sun, Nov 27, 2016 at 1:16 AM, Tom Lane wrote:
> If we just did points 1 and 2 then a bool GUC would suffice. I'm
> not sure how to handle all three cases cleanly. We could define
> default_index_tablespace as empty to get point 1 or a tablespace
> name to get point 3, but that leaves us havin
> I was thinking about introducing a new GUC, named something like
> default_index_tablespace, which would need to have at least these
> behaviors:
Should we also consider the chidren tables as mentioned by Corey?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Amit Kapila writes:
> What will such a storage parameter (default_tablespace) mean at table
> level and how it will different from existing default_tablespace? I
> think the usage asked by Amos is quite genuine, but not sure if
> introducing default_tablespace as a storage level parameter is the
On Sat, Nov 26, 2016 at 8:57 AM, Michael Paquier
wrote:
> On Sat, Nov 26, 2016 at 11:25 AM, Amos Bird wrote:
>> How about making a storage parameter "default_tablespace" that also
>> covers CREATE INDEX and other stuff?
>
> That's exactly the idea, the one at relation-level gets priority on
> the
On Sat, Nov 26, 2016 at 11:25 AM, Amos Bird wrote:
> How about making a storage parameter "default_tablespace" that also
> covers CREATE INDEX and other stuff?
That's exactly the idea, the one at relation-level gets priority on
the global one defined in postgresql.conf.
--
Michael
--
Sent via
> The only scenario where this would be useful is when using ALTER TABLE
> ADD CONSTRAINT in which case a fresh index is built (not USING INDEX).
> That's a bit narrow, because it would mean that you would either
> append a TABLESPACE clause to this existing clause, or create a
> storage parameter
> I had a similar problem in writing the range_partitioning extension: CREATE
> TABLE y (LIKE x INCLUDING ALL) didn't set the tablespace of y to match x.
> I don't have a solution, I'm just indicating a similar need in userland.
Cool, I didn't think of that. It seems this feature is at least usef
>
> I'd like to implement this small feature --- making table's auxiliary
> structures store their data to the target table's tablespace by default.
> I've done a thorough search over the mailing list and there is nothing
> relevant. Well I may miss some corners :-)
>
I had a similar problem in wr
On Fri, Nov 25, 2016 at 10:47 PM, Amos Bird wrote:
>> So you would like locate those index tablespaces into the same
>> tablespace as its parent relation when the index is created for a
>> unique index or as a primary key?
>
> Yes, and I'd like this behavior take effect when default_tablespace is
> So you would like locate those index tablespaces into the same
> tablespace as its parent relation when the index is created for a
> unique index or as a primary key?
Yes, and I'd like this behavior take effect when default_tablespace is
set to something like "parent".
> But what would be the
On Fri, Nov 25, 2016 at 4:48 PM, Amos Bird wrote:
> I've been using postgres for a long time. Recently I'm doing table
> sharding over a bunch of pgsql instances. I'm using multiple tablespaces
> one per disk to utilize all the IO bandwidth. Things went on pretty
> well, however there is a trouble
Dear pgsql community,
I've been using postgres for a long time. Recently I'm doing table
sharding over a bunch of pgsql instances. I'm using multiple tablespaces
one per disk to utilize all the IO bandwidth. Things went on pretty
well, however there is a troublesome problem I have when adding
aux
17 matches
Mail list logo
