When we checkpoint we write out all dirty buffers. But ISTM we don't really
need to write out buffers which are dirty but which have an LSN older than the
previous checkpoint. Those represent buffers which were dirtied by a
non-wal-logged modification, ie, hint bit setting. The other non-wal-logge
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Jan Wieck wrote:
>> You mean as a second, optional argument? Good idea.
>>
>> us = microseconds
>> ms = milliseconds
>> s = seconds (default)
>>
>> \sleep {value|:variable} [us|ms|s]
>>
>> Is that okay with everyone?
> I won't object, but is it
"Tom Lane" <[EMAIL PROTECTED]> writes:
>> That would be overly aggressive on a workload that's steady on average,
>> but consists of small bursts. Like this: 0 0 0 0 100 0 0 0 0 100 0 0 0 0
>> 100. You'd end up writing ~100 pages on every bgwriter round, but you
>> only need an average of 20 pa
FYI, I have massively reorganized the text search documentation and it
is getting closer to something I am happy with:
http://momjian.us/expire/fulltext/HTML/textsearch.html
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB ht
On Fri, 6 Jul 2007, Heikki Linnakangas wrote:
I've been running these test with bgwriter_delay of 10 ms, which is probably
too aggressive.
Even on relatively high-end hardware, I've found it hard to get good
results out of the BGW with the delay under 50ms--particularly when trying
to do som
Kevin Grittner wrote:
> This all started with the question about whether the documentation should
> say anything about vacuum schedules other than "enable autovacuum."
> My point was that I have a use case where I think that a scheduled vacuum
> will be better than leaving everything to autovacuum
>>> On Fri, Jul 6, 2007 at 2:19 PM, in message
<[EMAIL PROTECTED]>, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
> 2. The point of autovacuum is to get rid of maintenance burden, not add
> to it. If you know which tables are small and frequently updated, then
> configure th
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Well, if a table has 10 rows, and we keep the current threshold of 1000
rows, then this table must have 1002 dead tuples (99% dead tuples, 1002
dead + 10 live) before being vacuumed. This seems wasteful because
there are 500 dead tuples on it and
Heikki Linnakangas wrote:
I scheduled a test with the moving average method as well, we'll see how
that fares.
No too well :(.
Strange. The total # of writes is on par with having bgwriter disabled,
but the physical I/O graphs show more I/O (on par with the aggressive
bgwriter), and the resp
Hi guys,
I've played with PostgreSql for couple weeks. Currently, I try to develop an
extension on windows system with VC++2005. I installed the full package of
PostgreSql 8.3 with include files and libraries. Compilation is ok in
vc2005, besides some warnings. But, when I tried to run my functio
Kevin Grittner wrote:
> >>> On Tue, Jul 3, 2007 at 5:34 PM, in message
> <[EMAIL PROTECTED]>, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
> > Kevin Grittner wrote:
> >
> >> Autovacuum is enabled with very aggressive settings, to cover small
> >> tables, including one with about 75 rows that can
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >Jim C. Nasby wrote:
> >>FWIW, I normally go with the 8.2 defaults, though I could see dropping
> >>vacuum_scale_factor down to 0.1 or 0.15. I also think the thresholds
> >>could be decreased further, maybe divide by 10.
> >
> >How about pushing
On Fri, 6 Jul 2007, Tom Lane wrote:
The problem is that it'd be very hard to track how far ahead of the
recycling sweep hand we are, because that number has to be measured
in usage-count-zero pages. I see no good way to know how many of the
pages we scanned before have been touched (and given n
On 7/6/2007 1:32 PM, Heikki Linnakangas wrote:
Jan Wieck wrote:
On 7/6/2007 10:44 AM, Peter Eisentraut wrote:
Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck:
To test some changes in Slony I needed a
\usleep [microseconds|:variable]
in pgbench's scripting language to be able to have
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
imola-336 imola-337 imola-340
writes by checkpoint 38302 30410 39529
writes by bgwriter 350113 2205782 1418672
writes by backends 1834333
Jan Wieck wrote:
On 7/6/2007 10:44 AM, Peter Eisentraut wrote:
Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck:
To test some changes in Slony I needed a
\usleep [microseconds|:variable]
in pgbench's scripting language to be able to have hundreds of
concurrent running transactions wit
On 7/6/2007 10:44 AM, Peter Eisentraut wrote:
Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck:
To test some changes in Slony I needed a
\usleep [microseconds|:variable]
in pgbench's scripting language to be able to have hundreds of
concurrent running transactions without totally swamp
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> A long time ago, Tom proposed moving the pg_autovacuum settings into
> reloptions. I know it's really late in the devel cycle but I wonder if
> such a move would be acceptable at this time?
I think it's too late to be considering essentially-cosmetic c
Greg Smith <[EMAIL PROTECTED]> writes:
> On Thu, 5 Jul 2007, Tom Lane wrote:
>> This would give us a safety margin such that buffers_to_clean is not
>> less than the largest demand observed in the last 100 iterations...and
>> it takes quite a while for the memory of a demand spike to be forgotten
Hi,
A long time ago, Tom proposed moving the pg_autovacuum settings into
reloptions. I know it's really late in the devel cycle but I wonder if
such a move would be acceptable at this time? I feel it would be a good
move, for example per
http://thread.gmane.org/gmane.comp.db.postgresql.general/9
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
buffers_to_clean = Max(buffers_used * 1.1,
buffers_to_clean * 0.999);
That would be overly aggressive on a workload that's steady on average,
but consists of small bursts. Like this: 0 0 0 0 100 0 0 0 0 100 0 0 0
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> buffers_to_clean = Max(buffers_used * 1.1,
>> buffers_to_clean * 0.999);
> That would be overly aggressive on a workload that's steady on average,
> but consists of small bursts. Like this: 0 0 0 0 100 0 0 0 0 100 0 0 0 0
> 100.
Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck:
> To test some changes in Slony I needed a
>
> \usleep [microseconds|:variable]
>
> in pgbench's scripting language to be able to have hundreds of
> concurrent running transactions without totally swamping the system. I
> was wondering if an
Greg Smith wrote:
On Fri, 6 Jul 2007, Heikki Linnakangas wrote:
There's something wrong with that. The number of buffer allocations
shouldn't depend on the bgwriter strategy at all.
I was seeing a smaller (closer to 5%) increase in buffer allocations
switching from no background writer to us
On Fri, 6 Jul 2007, Heikki Linnakangas wrote:
There's something wrong with that. The number of buffer allocations shouldn't
depend on the bgwriter strategy at all.
I was seeing a smaller (closer to 5%) increase in buffer allocations
switching from no background writer to using the stock one b
Greg Smith wrote:
As you can see, I achieved the goal of almost never having a backend
write its own buffer, so yeah for that. That's the only good thing I
can say about it though. The TPS results take a moderate dive, and
there's about 10% more buffer allocations. The big and obvious issues
I just got my own first set of useful tests of using the new "remember
where you last scanned to" BGW implementation suggested by Tom. What I
did was keep the exiting % to scan, but cut back the number to scan when
so close to a complete lap ahead of the strategy point that I'd cross it
if I s
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
imola-336 imola-337 imola-340
writes by checkpoint 38302 30410 39529
writes by bgwriter 350113 2205782 1418672
writes by backends 1834333
Greg Smith wrote:
On Thu, 5 Jul 2007, Heikki Linnakangas wrote:
It looks like Tom's idea is not a winner; it leads to more writes than
necessary.
What I came away with as the core of Tom's idea is that the cleaning/LRU
writer shouldn't ever scan the same section of the buffer cache twice,
b
On Thu, 5 Jul 2007, Tom Lane wrote:
This would give us a safety margin such that buffers_to_clean is not
less than the largest demand observed in the last 100 iterations...and
it takes quite a while for the memory of a demand spike to be forgotten
completely.
If you tested this strategy even
On Thu, 5 Jul 2007, Jan Wieck wrote:
Original pgbench reported 39, 37 and 33 TPS. Having my patch applied it
reported 40, 38 and 33 TPS. Inserting a "\usleep 1" after the update to
accounts of a default equivalent script changed those numbers to 40, 37 and
33. I interpret that as "does not cha
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I'm wondering if a tsearch's configuration is bound to a language or
> an encoding. If it's bound to a language, there's a serious design
> problem, I would think. An encoding or charset is not necessarily
> bound to single language. We can find such that
32 matches
Mail list logo
