Tom Lane wrote:
The reason I didn't patch it myself is that I'm not quite clear on what
*should* be happening here. What effect should a large delete have on
the ANALYZE threshold, exactly? You could argue that a deletion
potentially changes the statistics (by omission), and therefore inserts,
Hi Tom, Alvaro,Thanks for your work on this. Please keep me posted as to which version in CVS this fix will be applied to and I will do my best to test it.Thanks again! --Dylan HansenEnterprise Systems DeveloperOn 27-Jun-06, at 5:42 AM, Alvaro Herrera wrote:Tom Lane wrote: Alvaro Herrera <[EMAIL P
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > + /* last_anl_tuples must never exceed n_live_tuples */
>
> If we actually believe the above statement, it seems like your patch
> to pgstat_recv_tabstat() opens a new issue: with that patch, it is
> possible for pgstat_rec
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> + /* last_anl_tuples must never exceed n_live_tuples */
If we actually believe the above statement, it seems like your patch
to pgstat_recv_tabstat() opens a new issue: with that patch, it is
possible for pgstat_recv_tabstat() to decrease n_
Dylan Hansen wrote:
> So can I assume that this is a bug?
Definitively a bug.
> The only resolution I can see right now is to setup a cron job that
> will perform an ANALYZE periodically, as the pg_autovacuum ANALYZE
> threshold is never reached.
>
> Any other suggestions? Thanks for the in
So can I assume that this is a bug?The only resolution I can see right now is to setup a cron job that will perform an ANALYZE periodically, as the pg_autovacuum ANALYZE threshold is never reached.Any other suggestions? Thanks for the input! --Dylan HansenEnterprise Systems DeveloperOn 24-Jun-06,
Tom Lane wrote:
Dylan Hansen <[EMAIL PROTECTED]> writes:
I have been spending some time looking into how auto-vacuum is
performing on one of our servers. After putting the PostgreSQL logs
in debug I noticed that the threshold for ANALYZE was never being hit
for a particular table becaus
Hi Tom, Alvaro. Thanks so much for your replies.On 22-Jun-06, at 12:56 PM, Alvaro Herrera wrote:Hmm ... I'd think that the number of dead tuples plus live tuples shouldnever be smaller than the number of tuples seen at last analyze. Unlesssome stats messages are lost (say, stop the server, start
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Apparently somehow last_anl_tuples has managed to get to be bigger than
>> n_live_tuples, which maybe could happen after a delete. Should we be
>> clamping last_anl_tuples to not exceed n_live_tuples somewhere?
>> Alvaro and Matthew,
Tom Lane wrote:
> Dylan Hansen <[EMAIL PROTECTED]> writes:
> > I have been spending some time looking into how auto-vacuum is
> > performing on one of our servers. After putting the PostgreSQL logs
> > in debug I noticed that the threshold for ANALYZE was never being hit
> > for a particular
Dylan Hansen <[EMAIL PROTECTED]> writes:
> I have been spending some time looking into how auto-vacuum is
> performing on one of our servers. After putting the PostgreSQL logs
> in debug I noticed that the threshold for ANALYZE was never being hit
> for a particular table because the calcula
Greetings all,I have been spending some time looking into how auto-vacuum is performing on one of our servers. After putting the PostgreSQL logs in debug I noticed that the threshold for ANALYZE was never being hit for a particular table because the calculated value becomes increasingly negative.W
12 matches
Mail list logo
