Re: WIP: Fast GiST index build
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: WIP: Fast GiST index build |
| Дата | |
| Msg-id | 4E07075E.30900@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: WIP: Fast GiST index build (Alexander Korotkov <aekorotkov@gmail.com>) |
| Список | pgsql-hackers |
On 25.06.2011 11:23, Alexander Korotkov wrote: > On Sat, Jun 25, 2011 at 11:03 AM, Jesper Krogh<jesper@krogh.cc> wrote: > >> * Wouldn't it be natural to measure the performance benefits of >> disc-bound tests in an SSD setup? >> > Sure, it would be great to run performance tests on SSD drives too. > Unfortunately, I don't have corresponding test platform just now. Anyone have an SSD setup to run some quick tests with this? >> In terms of random IO an SSD can easily be x100 better than rotating >> drives and it would be a shame to optimize "against" that world? > > Actually, I'm not sure that IO is bottle neck of GiST index build on SSD > drives. It's more likely for me that CPU becomes a bottle neck in this case > and optimizing IO can't give much benefit. But anyway, the value of this > work can be in producing better index in some cases and SSD drive lifetime > economy due to less IO operations. Yeah, this patch probably doesn't give much benefit on SSDs, not the order of magnitude improvements it gives on HDDs anyway. I would expect there to still be a small gain, however. If you look at the comparison of CPU times on Alexander's tests, the patch doesn't add that much CPU overhead: about 5% on the point_ops tests. I/O isn't free on SSDs either, so I would expect the patch to buy back that 5% increase in CPU overhead by reduced time spent on I/O even on a SSD. It's much worse on the gist_trgm_ops test case, so this clearly depends a lot on the opclass, but even that should be possible to optimize quite a bit. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: