> > Attached is a patch that adds support for specifying a location for
> > indexes via the "create database" command.
> >
> > I believe this patch is complete, but it is my first .
>
> This patch allows index locations to be specified as
> different from data locations. Is this a feature dir
> Moving the test to a system with SCSI disks gave different results.
> There is NO difference between having the indexes on the same disk or
> different disk with the data while running pgbench. So I
> leave it up to you guys as to include the patch or not. I do believe
> that even if performa
> Moving the test to a system with SCSI disks gave different results.
> There is NO difference between having the indexes on the same disk or
> different disk with the data while running pgbench. So I leave it up to
> you guys as to include the patch or not. I do believe that even if
> performa
Moving the test to a system with SCSI disks gave different results.
There is NO difference between having the indexes on the same disk or
different disk with the data while running pgbench. So I leave it up to
you guys as to include the patch or not. I do believe that even if
performance doesn'
Here is my pgbench results. As you can see the I am getting 2X tps with
the 2 directories. I believe this is a BIG win for Postgresql if we can
figure out the WAL recovery issues.
Can someone other than me apply the patch and verify the pgbench
results.
My hardward setup is a dual processor
I could also symlink all index files back to the tblnode directory?
> > I don't understand the WAL issue below, can you explain. The dir
name
> > is the same name as the database with _index added to it. This is
how
> > the current datpath stuff works. I really just copied the datpath
> > code
> Also I have been running this patch (both 7.1.3 and 7.2devel) against
> some of my companies applications. I have loaded a small database 10G
We are not familiar with your applications. It would be better to see
results of test suit available to the community. pgbench is first to
come in mind.
> I don't understand the WAL issue below, can you explain. The dir name
> is the same name as the database with _index added to it. This is how
> the current datpath stuff works. I really just copied the datpath
> code to get this patch to work...
At the time of after crash recovery WAL is not a
Vadim,
I don't understand the WAL issue below, can you explain. The dir name
is the same name as the database with _index added to it. This is how
the current datpath stuff works. I really just copied the datpath code
to get this patch to work...
Also I have been running this patch (both 7.1.
I agree that groups of objects in separate data storage areas are needed
and that is what I am trying to get to. Don't you think that Postgresql
with locations/files is the same as Oracle tablespaces. I don't think
we want to invent our own filesystem (which is what a tablespace really
is...).
just change the work tablespace below to location and that is exactly
what this patch is trying to do. You can think of the LOCATION and
INDEX_LOCATION provided to the create database command as the default
storage locations for these objects. In the future, I want to enable
the DBA to specify
> > The more general and "standard" way to go are TABLESPACEs.
> > But probably proposed feature will be compatible with
> > tablespaces, when we'll got them:
>
> Will it be? I'm afraid of creating a backwards-compatibility
> problem for ourselves when it comes time to implement tablespaces.
As
> ...
> > At the very least I'd like to see some information demonstrating
> > how much benefit there is to this proposed patch, before we
> > consider whether to adopt it. If there's a significant performance
> > benefit to splitting a PG database along the table-vs-index divide,
> > then it's i
...
> At the very least I'd like to see some information demonstrating
> how much benefit there is to this proposed patch, before we
> consider whether to adopt it. If there's a significant performance
> benefit to splitting a PG database along the table-vs-index divide,
> then it's interesting a
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > The more general and "standard" way to go are TABLESPACEs.
> > But probably proposed feature will be compatible with
> > tablespaces, when we'll got them:
>
> Will it be? I'm afraid of creating a backwards-compatibility
> problem for ourselves w
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> The more general and "standard" way to go are TABLESPACEs.
> But probably proposed feature will be compatible with
> tablespaces, when we'll got them:
Will it be? I'm afraid of creating a backwards-compatibility
problem for ourselves when it comes t
> > Attached is a patch that adds support for specifying a
> > location for indexes via the "create database" command.
> >
> > I believe this patch is complete, but it is my first .
>
> This patch allows index locations to be specified as
> different from data locations. Is this a feature direc
I am very new to this mailinglist so I apologize if I start talking early but
I've been working as a sysadmin and that kind of problems for a long while
now and my suggestion is that it is a start but I think that we should aim a
little higher than this and use something more like the Oracle appr
> > Attached is a patch that adds support for specifying a location for
> > indexes via the "create database" command.
> This patch allows index locations to be specified as different from data
> locations. Is this a feature direction we want to go in? Comments?
I have not looked at the patch,
> Hi all,
>
> Attached is a patch that adds support for specifying a location for
> indexes via the "create database" command.
>
> I believe this patch is complete, but it is my first .
This patch allows index locations to be specified as different from data
locations. Is this a feature direc
Hi all,
Attached is a patch that adds support for specifying a location for
indexes via the "create database" command.
I believe this patch is complete, but it is my first .
Thanks
Jim
location.diffs
---(end of broadcast)---
TIP 2: you can
21 matches
Mail list logo
