Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I also think we should remove these DEBUG messages, that are now
> useless:
> DEBUG: autovac: will ANALYZE bar
+1, those were just ad-hoc.
regards, tom lane
---(end of broadcast)---
On Wed, 2007-03-28 at 17:42 +0200, Pavel Stehule wrote:
> >
> >This is the most recent email I have on this. Was the scrollable patch
> >applied? If not, would you resubmit?
> >
>
> I resubmit scrollable cursor patch
I notice your patch has been accepted, though admit I hadn't noticed it
prev
Alvaro Herrera wrote:
> Seems fair. Updated patch attached.
>
> If there are no further comments, I'll add some docs and apply it later.
If autovacuum_vacuum_cost_delay is set to 20, my pitiful desktop system
takes 8.4 seconds to analyze a 8000 page table:
DEBUG: "bar": scanned 3000 of 8811 p
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >>> BTW, shouldn't the log entry distinguish whether this was VACUUM,
> >>> ANALYZE, or both?
> >>
> >> We don't actually log anything for ANALYZE (the logging code is in
> >> lazy_vacuum_
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> BTW, shouldn't the log entry distinguish whether this was VACUUM,
>>> ANALYZE, or both?
>>
>> We don't actually log anything for ANALYZE (the logging code is in
>> lazy_vacuum_rel).
>>
>> Maybe it should be
Alvaro Herrera wrote:
> Tom Lane wrote:
> > BTW, shouldn't the log entry distinguish whether this was VACUUM,
> > ANALYZE, or both?
>
> We don't actually log anything for ANALYZE (the logging code is in
> lazy_vacuum_rel).
>
> Maybe it should be in autovacuum.c.
The only problem with this is tha
On Tue, 2007-04-17 at 16:41 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > BTW, shouldn't the log entry distinguish whether this was VACUUM,
> > ANALYZE, or both?
>
> We don't actually log anything for ANALYZE (the logging code is in
> lazy_vacuum_rel).
When ANALYZE starts taking some time, w
Tom Lane wrote:
> BTW, shouldn't the log entry distinguish whether this was VACUUM,
> ANALYZE, or both?
We don't actually log anything for ANALYZE (the logging code is in
lazy_vacuum_rel).
Maybe it should be in autovacuum.c.
--
Alvaro Herrerahttp://www.CommandPro
BTW, shouldn't the log entry distinguish whether this was VACUUM,
ANALYZE, or both?
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comma
Maybe it would be interesting to see in detail those cases that got a
bit slower, to further tweak the heuristic if necessary. Is the extra
time, time spent in planning or in execution?
Since there doesn't seem to be vast interest out there in testing this
further, I'm going to go ahead and app
In response to Alvaro Herrera <[EMAIL PROTECTED]>:
> Simon Riggs wrote:
> > On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
>
> > > I've tinkered with this patch a bit. Sample output:
> > >
> > > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > > pages:
On Tue, 2007-04-17 at 14:45 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
>
> > > I've tinkered with this patch a bit. Sample output:
> > >
> > > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > > p
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Steve wrote:
>> So I'd say as far as I can tell with my application and my
>> dataset, this change is solid and an obvious improvement.
> Maybe it would be interesting to see in detail those cases that got a
> bit slower, to further tweak the heuristic
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Perhaps we need this as an integer, so we can log all vacuums that last
>> for longer in seconds than the setting, 0 logs all. That would
>> significantly reduce the volume if we set it to 5, say. That way you
>> would get your read
Simon Riggs wrote:
> On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
> > I've tinkered with this patch a bit. Sample output:
> >
> > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > pages: removed 0, 11226 remain
> > tuples: 1300683 removed, 1096
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I've tinkered with this patch a bit. Sample output:
>
> > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > pages: removed 0, 11226 remain
> > tuples: 1300683 removed, 1096236 remain
> >
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I've tinkered with this patch a bit. Sample output:
> LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> pages: removed 0, 11226 remain
> tuples: 1300683 removed, 1096236 remain
> system usage: CPU 0.29s/0.3
On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
> > > Maybe something like this is better:
> > >
> > > LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199,
> > > 2338 remain CPU usage
Simon Riggs wrote:
> On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
> > Maybe something like this is better:
> >
> > LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199,
> > 2338 remain CPU usage: whatever
> > CONTEXT: Automatic vacuuming of table "database.public
Tom Lane wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have to tell if the default expression is "5!"
or "5!GENERATED ...".
There are basically two ways to fix this:
Andrew Dunstan wrote:
> Tom Lane wrote:
> >The problem comes from cases like
> >
> > colname coltype DEFAULT 5! GENERATED ...
> >
> >Since b_expr allows postfix operators, it takes one more token of
> >lookahead than we have to tell if the default expression is "5!"
> >or "5!GENERATED ...".
> >
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> BTW I just noticed this bug in the comment above a_expr:
> * Note that '(' a_expr ')' is a b_expr, so an unrestricted expression can
> * always be used by surrounding it with parens.
> It is wrong because it's not a b_expr, but a c_expr.
Well, it's
Simon Riggs wrote:
New functions to examine the contents of heap pages, as discussed
recently on -hackers. These are fully integrated into backend.
...
I'll maintain this with immediate fixes/additions as we go up to 8.3 and
beyond, to assist review process of various patches that alter page
cont
Zoltan Boszormenyi írta:
Tom Lane írta:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Zoltan Boszormenyi wrote:
Thanks. This idea solved one of the two shift/reduce conflicts.
But the other one can only be solved if I put GENERATED
into the reserved_keyword set. But the standard spec says
i
Thank you for reporting!
I noticed that I need more examination the case when dsm relations or
dsm chunks are exhausted. I'll do more tests for DSM.
"Pavan Deolasee" <[EMAIL PROTECTED]> wrote:
> I was testing this patch when got this server crash. The patch is applied
> on the current CVS HEAD.
Tom Lane írta:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Zoltan Boszormenyi wrote:
Thanks. This idea solved one of the two shift/reduce conflicts.
But the other one can only be solved if I put GENERATED
into the reserved_keyword set. But the standard spec says
it's unreserved. Now what
26 matches
Mail list logo
