Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I found following mail in my mail archive and tried the same test with
> 7.4 current. Contrary to my expectation 7.4 showed some performance
> degration with continuous pgbench runs:
I did some profiling and found that with repeated runs, an increasing
a
Forgot to mention an important thing: I set enable_seqscan = off in
postgresql.conf.
> I found following mail in my mail archive and tried the same test with
> 7.4 current. Contrary to my expectation 7.4 showed some performance
> degration with continuous pgbench runs:
>
> $ pgbench -c 5 -t 1000
I found following mail in my mail archive and tried the same test with
7.4 current. Contrary to my expectation 7.4 showed some performance
degration with continuous pgbench runs:
$ pgbench -c 5 -t 1000 -n test
tps = 57.444037 (including connections establishing)
tps = 57.455300 (excluding connect
Joe Conway <[EMAIL PROTECTED]> writes:
> This may qualify as a "way out there" idea, or more trouble than it's
> worth, but what about a table option which provides a bitmap index of
> tuple status -- i.e. tuple dead t/f. If available, a seqscan in between
> vacuums could maybe gain some of the
On Sat, 2002-05-25 at 02:38, Joe Conway wrote:
> Tom Lane wrote:
> > The remaining degradation is actually in seqscan performance, not
> > indexscan --- unless one uses a much larger -s setting, the planner will
> > think it ought to use seqscans for updating the "branches" and "tellers"
> > table
Tom Lane wrote:
> The remaining degradation is actually in seqscan performance, not
> indexscan --- unless one uses a much larger -s setting, the planner will
> think it ought to use seqscans for updating the "branches" and "tellers"
> tables, since those nominally have just a few rows; and there'
> This is the first time I have ever seen repeated pgbench runs without
> substantial performance degradation. Not a bad result for a Friday
> afternoon...
Congatulations :-) This sounds great !!!
Andreas
---(end of broadcast)---
TIP 5: Have you
