Re: When does sequential performance matter in PG?
| От | Greg Smith |
|---|---|
| Тема | Re: When does sequential performance matter in PG? |
| Дата | |
| Msg-id | alpine.GSO.2.01.0903101338560.14397@westnet.com обсуждение |
| Ответ на | When does sequential performance matter in PG? (henk de wit <henk53602@hotmail.com>) |
| Список | pgsql-performance |
On Tue, 10 Mar 2009, henk de wit wrote: > Now I wonder if there is any situation in which sequential IO > performance comes into play. E.g. perhaps during a tablescan on a > non-fragmented table, or during a backup or restore? If you're doing a sequential scan of data that was loaded in a fairly large batch, you can approach reading at the sequential I/O rate of the drives. Doing a backup using pg_dump is one situation where you might actually do that. Unless your disk performance is really weak, restores in PostgreSQL are usually CPU bound right now. There's a new parallel restore feature in 8.4 that may make sequential write performance a more likely upper bound to run into, assuming your table structure is amenable to loading in parallel (situations with just one giant table won't benefit as much). -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-performance по дате отправления: