On Friday 14 September 2007, "Harsh Azad" <[EMAIL PROTECTED]> wrote:
> Great, creating new tablespace for indexes worked! Now the question is
> whether existing tables/index can be moved to the new tablespace using an
> alter command or the only way possible is to drop and recreate them?
>
ALTER T
On Sat, 2007-09-15 at 01:51 +0530, Harsh Azad wrote:
> Great, creating new tablespace for indexes worked! Now the question is
> whether existing tables/index can be moved to the new tablespace using
> an alter command or the only way possible is to drop and recreate
> them?
You can alter an existi
Great, creating new tablespace for indexes worked! Now the question is
whether existing tables/index can be moved to the new tablespace using an
alter command or the only way possible is to drop and recreate them?
Azad
On 9/14/07, Jean-David Beyer <[EMAIL PROTECTED]> wrote:
>
> Harsh Azad wrote:
On Fri, 14 Sep 2007, Peter Childs wrote:
Are you suggesting that reducing bgwriter_delay and bg_writer_percent
would reduce the time spent doing commits? I get quite a few commits
that take over 500ms (the point when i start logging queries).
One very common cause for transactions blocking fo
> > Isn't that the point of the documentation? I mean, if the existing,
> > official manual has been demonstrated (through countless mailing list
> > help requests) to not sufficiently explain a given topic, shouldn't
> > it be revised?
Or it proves that no one bothers to read the docs.
> > One
Harsh Azad wrote:
> Hi,
>
> Where are the database index files located in the $PGDATA directory? I
> was thinking on soft linking them to another physical hard disk array.
>
I am not an expert, but what I have done is put the Write-Ahead-Log on one
hard drive, some little-used relations and their
On 2007-09-14 soni de wrote:
> In Postgres 7.2.4, COPY command is working fine even if tables have 6
> fields but we are copying only 5 fields from the file
>
> But in Postgres 8.2.0, if table has 6 fields and we need to copy data
> for 5 fields only, then we need to specify the column names too i
> I'm having a problem with long running commits appearing in my database
> logs. It may be hardware related, as the problem appeared when we moved
> the database to a new server connected to a different disk array. The
> disk array is a lower class array, but still more than powerful enough
> to
Hello,
In Postgres 7.2.4, COPY command is working fine even if tables have 6 fields
but we are copying only 5 fields from the file
But in Postgres 8.2.0, if table has 6 fields and we need to copy data for 5
fields only, then we need to specify the column names too in COPY command.
Is there any
Le vendredi 14 septembre 2007 à 11:09 +0800, Ow Mun Heng a écrit :
> On Fri, 2007-09-14 at 08:33 +0530, Harsh Azad wrote:
> > ah.. thanks. Didn't realize table spaces can be mentioned while
> > creating a index. BTW, are soft links ok to use for pg_clog /
> > pg_xlog . I moved the existing director
On 14/09/2007, Peter Childs <[EMAIL PROTECTED]> wrote:
>
>
>
> On 13/09/2007, Greg Smith <[EMAIL PROTECTED]> wrote:
> >
> >
> > Every time the all scan writes a buffer that is frequently used, that
> > write has a good chance that it was wasted because the block will be
> > modified again before ch
On Thu, 13 Sep 2007, Scott Marlowe wrote:
I think both things are needed actually. The current docs were
started back when pg 7.2 roamed the land, and they've been updated a
bit at a time...
No argument here that ultimately the documentation needs to be updated as
well. I was just suggestin
On 13/09/2007, Greg Smith <[EMAIL PROTECTED]> wrote:
>
>
> Every time the all scan writes a buffer that is frequently used, that
> write has a good chance that it was wasted because the block will be
> modified again before checkpoint time. Your settings are beyond regular
> aggressive and into th
13 matches
Mail list logo
