[EMAIL PROTECTED] wrote:
I have been testing the performance of PostgreSQL using the simple tool
found at _http://benchw.sourceforge.net_ however I have found that all
the queries it run execute with sequential scans. The website where the
code runs has examples of the execution plan using inde
Tom Lane wrote:
<[EMAIL PROTECTED]> writes:
I have been testing the performance of PostgreSQL using the simple tool
found at http://benchw.sourceforge.net however I have found that all the
queries it run execute with sequential scans. The website where the code
runs has examples of the execution
"Craig A. James" <[EMAIL PROTECTED]> writes:
> This causes massive file-system activity and flushes all files that the
> kernel has cached. If you run this between each Postgres test (let it run
> for a couple minutes), it gives you an apples-to-apples comparison between
> successive benchmarks, a
The real issue here is caching across successive queries, an effect that
Postgres doesn't deal with very well at the moment. If you run these
queries from a standing start (freshly booted machine) you'll likely
find that the indexscan plan is indeed slower than the seqscan/hash
plan, just like th
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Isn't there any way to make PostgreSQL have a better estimation here:
> -> Index Scan using models_brands_brand on models_brands
> (cost=0.00..216410.97 rows=92372 width=0) (actual time=0.008..0.008
> rows=0 loops=303)
>Index Cond: (brand
<[EMAIL PROTECTED]> writes:
> I have been testing the performance of PostgreSQL using the simple tool
> found at http://benchw.sourceforge.net however I have found that all the
> queries it run execute with sequential scans. The website where the code
> runs has examples of the execution plan using
