Re: Transparent table partitioning in future version of PG?
В списке pgsql-performance по дате отправления:
| От | Craig Ringer |
|---|---|
| Тема | Re: Transparent table partitioning in future version of PG? |
| Дата | |
| Msg-id | 4A04DB92.1060405@postnewspapers.com.au обсуждение исходный текст |
| Ответ на | Re: Transparent table partitioning in future version of PG? (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-performance |
Robert Haas wrote: > Well, even if the table is not partitioned at all, I don't see that it > should preclude parallel query access. If I've got a 1 GB table that > needs to be sequentially scanned for rows meeting some restriction > clause, and I have two CPUs and plenty of I/O bandwidth, ISTM it > should be possible to have them each scan half of the table and > combine the results. Now, this is not easy and there are probably > substantial planner and executor changes required to make it work, but > I don't know that it would be particularly easier if I had two 500 MB > partitions instead of a single 1 GB table. The point of partitioning in this scenario is primarily that you can put the different partitions in different tablespaces, most likely on independent disk devices. You therefore get more I/O bandwidth. -- Craig Ringer
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера