From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Marginal performance improvement: replace bms_first_member loops |
Date: | 2014-11-28 15:08:36 |
Message-ID: | 9024.1417187316@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 27 November 2014 at 19:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 like
prevbit = (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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-11-28 15:11:40 | Re: Marginal performance improvement: replace bms_first_member loops |
Previous Message | Noah Misch | 2014-11-28 14:17:31 | Re: The problems of PQhost() |