Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)
От | Tom Lane |
---|---|
Тема | Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build) |
Дата | |
Msg-id | 15195.1317330983@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast
GiST index build)
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Looking at the big picture, however, the real problem with all those > makesign() calls is that they happen in the first place. They happen > when gist needs to choose which child page to place a new tuple on. It > calls the penalty for every item on the internal page, always passing > the new key as the 2nd argument, along the lines of: > for (all items on internal page) > penalty(item[i], newitem); > At every call, gtrgm_penalty() has to calculate the signature for > newitem, using makesign(). That's an enormous waste of effort, but > there's currently no way gtrgm_penalty() to avoid that. Hmm. Are there any other datatypes for which the penalty function has to duplicate effort? I'm disinclined to fool with this if pg_trgm is the only example ... but if it's not, maybe we should do something about that instead of micro-optimizing makesign. regards, tom lane
В списке pgsql-hackers по дате отправления: