On Monday 27 August 2007 16:04:39 Decibel! wrote:
> On Mon, Aug 27, 2007 at 04:56:33PM -0500, Kevin Grittner wrote:
> > >>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>>
> > >>>
> > > > > They're running version 8.1.4
> > >
> > > As for your pg_dump idea... why not just do a CREATE TABLE AS SE
On Monday 27 August 2007 15:00:41 you wrote:
> On Fri, Aug 24, 2007 at 04:41:44PM -0400, Bill Moran wrote:
> > In response to Kevin Kempter <[EMAIL PROTECTED]>:
> > > Hi List;
> > >
> > > I've just started working with a client that has been running Postgres
> > > (with no DBA) for a few years. The
On Mon, Aug 27, 2007 at 04:56:33PM -0500, Kevin Grittner wrote:
> >>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>>
> > > > They're running version 8.1.4
> >
> > As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT *
> > FROM bloated_table? That would likely be much faster th
On Monday 27 August 2007 15:56:33 Kevin Grittner wrote:
> >>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>>
> >>>
> > > > They're running version 8.1.4
> >
> > As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT *
> > FROM bloated_table? That would likely be much faster than m
>>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>>
> > > They're running version 8.1.4
>
> As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT *
> FROM bloated_table? That would likely be much faster than messing around
> with pg_dump.
He wanted to upgrade to 8.2.4. CREATE
On Fri, Aug 24, 2007 at 04:41:44PM -0400, Bill Moran wrote:
> In response to Kevin Kempter <[EMAIL PROTECTED]>:
>
> > Hi List;
> >
> > I've just started working with a client that has been running Postgres
> > (with
> > no DBA) for a few years. They're running version 8.1.4 on 4-way dell boxes
On Friday 24 August 2007 15:39:22 Tom Lane wrote:
> Kevin Kempter <[EMAIL PROTECTED]> writes:
> > The development folks that have been here awhile tell me that it seems
> > like when they have a query (not limited to vacuum processes) that has
> > been running for a long time (i.e. > 5 or 6 hours)
Kevin Kempter <[EMAIL PROTECTED]> writes:
> The development folks that have been here awhile tell me that it seems like
> when they have a query (not limited to vacuum processes) that has been
> running for a long time (i.e. > 5 or 6 hours) that the query sort of "goes
> crazy" and the entire sy
In response to "Kevin Grittner" <[EMAIL PROTECTED]>:
> >>> On Fri, Aug 24, 2007 at 2:57 PM, in message
> <[EMAIL PROTECTED]>, Kevin Kempter
> <[EMAIL PROTECTED]> wrote:
> >c) setup WAL archiving on the 8.1.4 cluster
> >
> >d) do a full dump of the 8.1.4 cluster and restore it to the new
>>> On Fri, Aug 24, 2007 at 2:57 PM, in message
<[EMAIL PROTECTED]>, Kevin Kempter
<[EMAIL PROTECTED]> wrote:
>c) setup WAL archiving on the 8.1.4 cluster
>
>d) do a full dump of the 8.1.4 cluster and restore it to the new 8.2.4
> cluster
>
>e) stop the 8.2.4 cluster and bring it u
In response to Kevin Kempter <[EMAIL PROTECTED]>:
> Hi List;
>
> I've just started working with a client that has been running Postgres (with
> no DBA) for a few years. They're running version 8.1.4 on 4-way dell boxes
> with 4Gig of memory on each box attached to RAID-10 disk arrays.
>
> So
Hi List;
I've just started working with a client that has been running Postgres (with
no DBA) for a few years. They're running version 8.1.4 on 4-way dell boxes
with 4Gig of memory on each box attached to RAID-10 disk arrays.
Some of their key config settings are here:
shared_buffers = 20480
12 matches
Mail list logo
