Re: Re: low performance - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Re: low performance
Date
Msg-id 4462.999534399@sss.pgh.pa.us
Whole thread Raw
In response to low performance  (Andreas Wernitznig <andreas@insilico.com>)
Responses Re: Re: low performance
List pgsql-bugs
Andreas Wernitznig <andreas@insilico.com> writes:
> To make it more comparable I have made two additional runs, a slow and
> a fast one with exactly the same number of inserts (about 20500) and
> put it on our ftp server:

>> However, I think what is happening is that some queries are being done
>> as indexscans in the fast case and seqscans in the slow case.  The
>> ratio of ExecIndexScan calls to ExecSeqScan calls is vastly different
>> in the two profiles.

> Does the new profiles proof that assumption ?

Yes, see for yourself:
def.fast:
  0.00      0.00     0.00    22481     0.00     0.00  ExecSeqScan
  0.00      0.00     0.00    20161     0.00     0.00  ExecIndexScan
def.slow:
  0.00      0.01     0.00    41940     0.00     0.00  ExecSeqScan
  0.00      0.01     0.00      702     0.00     0.00  ExecIndexScan

So there are about 19500 queries that are being done as indexscans in
one case and seqscans in the other.

> If I run "vacuum" and "vacuum analyze" on an empty database, the
> following run will be a SLOW one.

The whole point of vacuum analyze is to give the planner some statistics
about the contents of the tables.  Vacuum analyze when a table is empty
is useless (even counterproductive, if the table shortly thereafter
becomes large --- the planner will still think it is empty).

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: postmaster quits
Next
From: Tom Lane
Date:
Subject: Re: Re: low performance