Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Incidentally the visibility bugs are indeed entirely fixed in 8.3. In 8.2 and
>> before cluster and alter table rewrites can both cause tuples to not appear
>> for transactions which were started before the cluster
Gregory Stark <[EMAIL PROTECTED]> writes:
> Incidentally the visibility bugs are indeed entirely fixed in 8.3. In 8.2 and
> before cluster and alter table rewrites can both cause tuples to not appear
> for transactions which were started before the cluster or alter table such as
> a long-running pg
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Thu, Sep 11, 2008 at 8:56 AM, Bill Moran
> <[EMAIL PROTECTED]> wrote:
>> In response to Alvaro Herrera <[EMAIL PROTECTED]>:
>>
>>> Bill Moran wrote:
>>> > In response to "Gauthier, Dave" <[EMAIL PROTECTED]>:
>>> >
>>> > > I might be able to answer m
On Thu, Sep 11, 2008 at 11:15 AM, Alan Hodgson <[EMAIL PROTECTED]> wrote:
> On Thursday 11 September 2008, "Gauthier, Dave" <[EMAIL PROTECTED]>
> wrote:
>> I have a job that loads a large table, but then has to "update" about
>> half the records for various reasons. My perception of what happens o
On Thursday 11 September 2008, "Gauthier, Dave" <[EMAIL PROTECTED]>
wrote:
> I have a job that loads a large table, but then has to "update" about
> half the records for various reasons. My perception of what happens on
> update for a particular recors is...
>
> - a new record will be inserted wi
On Thu, Sep 11, 2008 at 8:56 AM, Bill Moran
<[EMAIL PROTECTED]> wrote:
> In response to Alvaro Herrera <[EMAIL PROTECTED]>:
>
>> Bill Moran wrote:
>> > In response to "Gauthier, Dave" <[EMAIL PROTECTED]>:
>> >
>> > > I might be able to answer my own question...
>> > >
>> > > vacuum FULL (analyze is
In response to Alvaro Herrera <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > In response to "Gauthier, Dave" <[EMAIL PROTECTED]>:
> >
> > > I might be able to answer my own question...
> > >
> > > vacuum FULL (analyze is optional)
> >
> > CLUSTER _may_ be a better choice, but carefully read the d
Bill Moran wrote:
> In response to "Gauthier, Dave" <[EMAIL PROTECTED]>:
>
> > I might be able to answer my own question...
> >
> > vacuum FULL (analyze is optional)
>
> CLUSTER _may_ be a better choice, but carefully read the docs regarding
> it's drawbacks first. You may want to do some bench
In response to "Gauthier, Dave" <[EMAIL PROTECTED]>:
> I might be able to answer my own question...
>
> vacuum FULL (analyze is optional)
CLUSTER _may_ be a better choice, but carefully read the docs regarding
it's drawbacks first. You may want to do some benchmarks to see if it's
really needed
Brad Nicholson wrote:
> If you want to compact the the table, you either need to use CLUSTER or
> VACUUM FULL + REINDEX.
Actually those are all pretty slow. If you can do a no-op ALTER TYPE
that rewrites the entire table, it is a lot faster. Something like
ALTER TABLE tab ALTER COLUMN col TYPE
On Thu, 2008-09-11 at 07:01 -0700, Gauthier, Dave wrote:
> Hi:
>
>
>
> I have a job that loads a large table, but then has to “update” about
> half the records for various reasons. My perception of what happens
> on update for a particular recors is...
>
> - a new record will be inserted with
I might be able to answer my own question...
vacuum FULL (analyze is optional)
Correct?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gauthier, Dave
Sent: Thursday, September 11, 2008 10:01 AM
To: pgsql-general@postgresql.org
Subject: [GEN
12 matches
Mail list logo
