Re: GiST index for pgtrgm bloats a lot
От | hubert depesz lubaczewski |
---|---|
Тема | Re: GiST index for pgtrgm bloats a lot |
Дата | |
Msg-id | 20150518133648.GA22898@depesz.com обсуждение исходный текст |
Ответ на | Re: GiST index for pgtrgm bloats a lot (Heikki Linnakangas <hlinnaka@iki.fi>) |
Список | pgsql-bugs |
On Mon, May 18, 2015 at 04:19:41PM +0300, Heikki Linnakangas wrote: > Are the columns that are included in the bloated index also updated that > often? If not, I'd suggest moving those columns to a separate table with a > one-to-one relationship to the main table. Or perhaps just create a helper > table that contains copies of those columns, and keep it up-to-date with > triggers. That would reduce the churn in the index. I'm not sure if this is possible, but will look into it. > 1. When GiST has multiple equally good choices where it could insert a > tuple, it favours branches that are "earlier" in the index. Always > descending down the same branch is good for cache efficiency when you insert > multiple items with similar keys, but the downside is that the other > branches can easily have a lot of free space that goes unused, while the > "hot" branch just gets split repeatedly. This is explained in the comments > in the gistchoose() function. That leads to bloat, because the free space > isn't being used. This looks related. Too bad that we don't have any other way to handle it, but at the very least I know it's not some "bug", it's just a missing feature. Thanks a lot, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/
В списке pgsql-bugs по дате отправления: