Re: Marginal performance improvement: replace bms_first_member loops
От | Tom Lane |
---|---|
Тема | Re: Marginal performance improvement: replace bms_first_member loops |
Дата | |
Msg-id | 9024.1417187316@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Marginal performance improvement: replace bms_first_member loops (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Список | pgsql-hackers |
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On 27 November 2014 at 19:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The attached proposed patch adds bms_next_member() and replaces >> bms_first_member() calls where it seemed to make sense. > There is another micro-optimisation that you could make in > bms_next_member() -- it isn't necessary to do > w = RIGHTMOST_ONE(w) Excellent point! Thanks for noticing that. > Should this function protect against large negative inputs? As it > stands, passing in a value of prevbit less than -1 would be > problematic. Maybe it's sufficient to say "don't do that" in the docs, > rather than waste more cycles checking. Yeah, I had considered whether to do that; instead of just prevbit++ it would need to be something likeprevbit = (prevbit < 0) ? 0 : prevbit + 1; This would add one test-and-branch, and moreover one that would be hard to predict correctly (given that most of our bitmapsets don't have very many members). So it seems pretty expensive. Probably a more explicit warning in the header comment is good enough; or we could put in an Assert(). regards, tom lane
В списке pgsql-hackers по дате отправления: