Re: Better tracking of free space during SP-GiST index build
От | Tomas Vondra |
---|---|
Тема | Re: Better tracking of free space during SP-GiST index build |
Дата | |
Msg-id | 77ac3599-e445-e0aa-6add-e6acad07afa3@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Better tracking of free space during SP-GiST index build (Oleg Bartunov <obartunov@gmail.com>) |
Ответы |
Re: Better tracking of free space during SP-GiST index build
|
Список | pgsql-hackers |
On 09/25/2016 08:33 PM, Oleg Bartunov wrote: > On Sat, Sep 24, 2016 at 11:32 PM, Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: >> On 09/22/2016 07:37 PM, Tom Lane wrote: >>> >>> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: >>> >>>> ... I've tried increasing the cache size to 768 >>>> entries, with vast majority of them (~600) allocated to leaf pages. >>>> Sadly, this seems to only increase the CREATE INDEX duration a bit, >>>> without making the index significantly smaller (still ~120MB). >>> >>> >>> Yeah, that's in line with my results: not much further gain from a >>> larger cache. Though if you were testing with the same IRRExplorer >>> data, it's not surprising that our results would match. Would be >>> good to try some other cases... >>> >> >> Agreed, but I don't have any other data sets at hand. One possibility would >> be to generate something randomly (e.g. it's not particularly difficult to >> generate random IP addresses), but I'd much rather use some real-world data >> sets. > > Tomas, I have one real dataset, which I used for testing spgist > (https://www.postgresql.org/message-id/CAF4Au4zxd2XOV0A__FU7xoHxSiwJzm1z2xhs-FFaT1DzB9ub3Q@mail.gmail.com) > Let me know if you need it. > Sure, that would be useful. I think it would be useful to make repository of such data sets, so that patch authors & reviewers can get a reasonable collection of data sets if needed, instead of scrambling every time. Opinions? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: