On Tue, Jun 28, 2005 at 10:36:58AM -0700, Dann Corbit wrote:
Nope, truncate is undoubtedly faster. But it also means you would have
downtime as you mentioned. If it were me, I'd probably make the
trade-off of using a delete inside a transaction.
For every record in a bulk loaded table?
Sure.
On Tue, Jun 28, 2005 at 10:36:58AM -0700, Dann Corbit wrote:
> > Nope, truncate is undoubtedly faster. But it also means you would have
> > downtime as you mentioned. If it were me, I'd probably make the
> > trade-off of using a delete inside a transaction.
>
> For every record in a bulk loaded ta
> -Original Message-
> From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 27, 2005 6:55 PM
> To: Dann Corbit
> Cc: Ben-Nes Yonatan; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Populating huge tables each day
>
> On Mon, Jun 27, 2005 a
> Subject: Re: [GENERAL] Populating huge tables each day
> >
> > On Mon, Jun 27, 2005 at 12:43:57PM -0700, Dann Corbit wrote:
> > > I see a lot of problems with this idea.
> > >
> > > You mention that the database is supposed to be available 24
> -Original Message-
> From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 27, 2005 12:58 PM
> To: Dann Corbit
> Cc: Ben-Nes Yonatan; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Populating huge tables each day
>
> On Mon, Jun 27, 2005 a
On Mon, Jun 27, 2005 at 12:43:57PM -0700, Dann Corbit wrote:
> I see a lot of problems with this idea.
>
> You mention that the database is supposed to be available 24x7.
> While you are loading, the database table receiving data will not be
> available. Therefore, you will have to have one serve
I see a lot of problems with this idea.
You mention that the database is supposed to be available 24x7.
While you are loading, the database table receiving data will not be
available. Therefore, you will have to have one server online (with
only the old data), while the other one is loading. Onc
