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
Per previous discussion, I have committed changes that cause the btree
and hash index methods to mark index tuples "killed" the first time they
are fetched after becoming globally dead. Subsequently the killed
entries are not returned out of indexscans, saving useless heap fetches.
(I haven't cha
