On Fri, 18 Jul 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > [EMAIL PROTECTED] writes:
> > > I disagree. Just as you can have multiple schemas within one database
> > > you can have multiple tablespaces within one database.
> >
> > > And the tablespace is irrelevant as far as specifying an
> Another good reason for per-database directories under the tablespace is
> to prevent directories from containing too many files.
Actually, I would take that as an reason not to have database
directories.
If the number of files becomes a concern, we would need some kind of a
hashing algorithm t
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I disagree. Just as you can have multiple schemas within one database
> > you can have multiple tablespaces within one database.
>
> > And the tablespace is irrelevant as far as specifying an object is concerned.
> > A fully qualified object would
On Wednesday 25 June 2003 21:21, Jonathan Bartlett wrote:
> My solution did not involve tablespaces, but was more of a quick solution
> to make it easier for admins to do _some_ sort of physical configuration.
>
> The idea is that the developer could do something like
>
> 'create alternate location
> Well, correct solution is to implement tablespaces on which objects like
> databases, tables and indexes can be put.
I've not looked at the SQL standard, but it seems to me like the order
should be:
Databases
Tablespaces
Schemas
Objects (tables, indexes, functions, etc.)
A
My solution did not involve tablespaces, but was more of a quick solution
to make it easier for admins to do _some_ sort of physical configuration.
The idea is that the developer could do something like
'create alternate location ALTERNATE_LOCATION_NAME for
DATABASE_OBJECT_NAME at "/PATH/TO/PHYSI
En un mensaje anterior, [EMAIL PROTECTED] escribió:
> > Well, correct solution is to implement tablespaces on which objects like
> > databases, tables and indexes can be put.
>
> I've not looked at the SQL standard, but it seems to me like the order
> should be:
>
> Databases
>Tablespaces
On Wed, 2003-06-25 at 10:51, Jonathan Bartlett wrote:
> My solution did not involve tablespaces, but was more of a quick solution
> to make it easier for admins to do _some_ sort of physical configuration.
>
> The idea is that the developer could do something like
>
> 'create alternate location A
> ROTFL... the answer is no. Feature freeze is Tuesday, people. In
> practice, the time to start coding new stuff is already long past.
> Especially major new stuff.
>
> If you start now you might have something done for 7.5.
Can everyone who is interested in actually coding a tablespaces
implem
> > Tablespaces
> > databases
> >schemas
> > objects
> >
> > with each of them implemented as a directory and data files under it. If
we
> > could get a quota check propogated in both direction, that would be
pretty
> > good, may be a warning when things start getting close to limit.
Dat
> Good question.
>
> If it gets in 7.4, that would be more than a killer feature to put against
7.4
> release, with due respect to all other enhancements in progress..
It's not going to happen.
Chris
---(end of broadcast)---
TIP 6: Have you search
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote:
> >> Is this doable within the time frame for the 7.4 feature freeze?
>
> > Good question.
>
> ROTFL... the answer is no. Feature freeze is Tuesday, people. In
> practice, the time to
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote:
>> Is this doable within the time frame for the 7.4 feature freeze?
> Good question.
ROTFL... the answer is no. Feature freeze is Tuesday, people. In
practice, the time to start coding ne
[EMAIL PROTECTED] writes:
> Being able to zap a database with one or more 'rm -rf' commands assumes
> that there will be files from just ONE database permitted in any given
> tablespace, and ONLY files from that database.
I said no such thing. Look at the structure again:
$PGDATA/base/dboid/..
On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote:
> Is this doable within the time frame for the 7.4 feature freeze?
Good question.
If it gets in 7.4, that would be more than a killer feature to put against 7.4
release, with due respect to all other enhancements in progress..
Shridhar
> > Well, with above proposal, drop database should be as simple. It's just that
> > it would be more than one `rm -rf`rather than just one.
>
> Right, there would be potentially one per tablespace. The key point
> here is that the tablespace definitions are known cluster-wide, so a
> "DROP DATA
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> On Thursday 26 June 2003 21:29, Tom Lane wrote:
>> I can see no reason that we'd want a level of directory associated with
>> schemas...
> Moving a multi-hundreds-of-GB table across schemas would be sooo easy..:-)
No, it would be harder.
On Thursday 26 June 2003 21:29, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > Well, consider this. Keep in mind that all of them are directories..
>
> I can see no reason that we'd want a level of directory associated with
> schemas...
Moving a multi-hundreds-of-GB table a
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Well, consider this. Keep in mind that all of them are directories..
I can see no reason that we'd want a level of directory associated with
schemas...
> Well, with above proposal, drop database should be as simple. It's just that
> it would be m
On Thursday 26 June 2003 20:22, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I disagree. Just as you can have multiple schemas within one database
> > you can have multiple tablespaces within one database.
> >
> > And the tablespace is irrelevant as far as specifying an object is
> > concerned.
[EMAIL PROTECTED] writes:
> I disagree. Just as you can have multiple schemas within one database
> you can have multiple tablespaces within one database.
> And the tablespace is irrelevant as far as specifying an object is concerned.
> A fully qualified object would be:
> database.schema.
> That should be
>
> Tablespaces
> databases
>schemas
> objects
>
> with each of them implemented as a directory and data files under it. If we
> could get a quota check propogated in both direction, that would be pretty
> good, may be a warning when things start getting close to lim
On Wednesday 25 June 2003 20:49, [EMAIL PROTECTED] wrote:
> > Well, correct solution is to implement tablespaces on which objects like
> > databases, tables and indexes can be put.
>
> I've not looked at the SQL standard, but it seems to me like the order
> should be:
>
> Databases
>Tablespaces
johnn wrote:
On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote:
DB2 looks good. I have horrid, horrid memories of wrestling with the
Oracle "extent" madness.
I do think that it's worth providing additional access points to
tablespaces, though. That is, it would make sense
> DB2 looks good. I have horrid, horrid memories of wrestling with the Oracle
> "extent" madness.
I think Oracle's extents came from their fixed size data file legacy, in 9i
the extent limits appear to be completely overridable and sometimes even
ignored, such as the next extent size. I agree th
On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote:
> DB2 looks good. I have horrid, horrid memories of wrestling with the
> Oracle "extent" madness.
I do think that it's worth providing additional access points to
tablespaces, though. That is, it would make sense to me to allow
"CREAT
DB2 looks good. I have horrid, horrid memories of wrestling with the Oracle
"extent" madness.
andrew
AgentM wrote:
> On Wednesday, June 25, 2003, at 12:10 PM, johnn wrote:
>> On Wed, Jun 25, 2003 at 11:34:14AM -0400, Tom Lane wrote:
>>> Has anyone looked at the syntaxes used by other databas
On Wed, 25 Jun 2003, Tom Lane wrote:
> Has anyone looked at the syntaxes used by other databases to control
> tablespaces (Oracle, DB2, etc)? I have no strong desire to slavishly
> follow Oracle, but it would be a shame to miss out on any good ideas.
>
Informix is pretty bad.
First, you use an ex
On Wednesday, June 25, 2003, at 12:10 PM, johnn wrote:
On Wed, Jun 25, 2003 at 11:34:14AM -0400, Tom Lane wrote:
Has anyone looked at the syntaxes used by other databases to control
tablespaces (Oracle, DB2, etc)? I have no strong desire to
slavishly follow Oracle, but it would be a shame to m
On Wed, Jun 25, 2003 at 11:34:14AM -0400, Tom Lane wrote:
> Has anyone looked at the syntaxes used by other databases to control
> tablespaces (Oracle, DB2, etc)? I have no strong desire to
> slavishly follow Oracle, but it would be a shame to miss out on any
> good ideas.
DB2:
CREATE TABLESPACE
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I have started working on tablespaces (to the extent that I am capable!),
> based not on the rejected patch, but on Jim's eventual syntax proposal that
> was never developed.
Has anyone looked at the syntaxes used by other databases to contro
On 25 Jun 2003 at 12:30, Shridhar Daithankar wrote:
> On 25 Jun 2003 at 14:55, Christopher Kings-Lynne wrote:
>
> > > Well, correct solution is to implement tablespaces on which objects like
> > > databases, tables and indexes can be put.
> >
> > I have started working on tablespaces (to the ext
> > I have started working on tablespaces (to the extent that I am
capable!),
> > based not on the rejected patch, but on Jim's eventual syntax proposal
that
> > was never developed.
>
> Hmm... Remember feature freeze is 1st of July. So unless you send out a
> minimally working patch before that, i
On 25 Jun 2003 at 14:55, Christopher Kings-Lynne wrote:
> > Well, correct solution is to implement tablespaces on which objects like
> > databases, tables and indexes can be put.
>
> I have started working on tablespaces (to the extent that I am capable!),
> based not on the rejected patch, but o
> Well, correct solution is to implement tablespaces on which objects like
> databases, tables and indexes can be put.
I have started working on tablespaces (to the extent that I am capable!),
based not on the rejected patch, but on Jim's eventual syntax proposal that
was never developed.
eg.
CR
On 24 Jun 2003 at 14:48, Jonathan Bartlett wrote:
> I know the current method for specifying alternate drives for PG tables is
> by using symlinks. I had some ideas for simple ways to do this in PG
> code, but wanted to know if anyone was working on this right now. I'd
> hate to take the time to
36 matches
Mail list logo
