Re: SSI patch version 8

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
 
> where exactly is the extra overhead coming from?
 
Keep in mind that this is a sort of worst case scenario.  The data
is fully cached in shared memory and we're doing a sequential pass
just counting the rows.  In an earlier benchmark (which I should
re-do after all this refactoring), random access queries against a
fully cached data set only increased run time by 1.8%.  Throw some
disk access into the mix, and the overhead is likely to get lost in
the noise.
 
But, as I said, count(*) seems to be the first thing many people try
as a benchmark, and this is a symptom of a more general issue, so
I'd like to find a good solution.
 
-Kevin