Re: Forcing using index instead of sequential scan?
| От | Craig A. James |
|---|---|
| Тема | Re: Forcing using index instead of sequential scan? |
| Дата | |
| Msg-id | 44C25FDD.8070003@modgraph-usa.com обсуждение исходный текст |
| Ответ на | Re: Forcing using index instead of sequential scan? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Forcing using index instead of sequential scan?
Re: Forcing using index instead of sequential scan? |
| Список | pgsql-performance |
> 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 the planner thinks.
Here's a little trick I learned to speed up this test.
find / -type f -exec grep foobar {} \;
This causes massive file-system activity and flushes all files that the kernel has cached. If you run this between
eachPostgres test (let it run for a couple minutes), it gives you an apples-to-apples comparison between successive
benchmarks,and eliminates the effects of caching.
If you run this as a regular user (NOT super-user or 'postgres'), you won't have permission to access your Postgres
files,so you're guaranteed they'll be flushed from the cache.
Craig
В списке pgsql-performance по дате отправления: