Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376) |
| Дата | |
| Msg-id | CA+TgmoYNO8qouPVO=1Q2aXzuxe942d_T5bcvZd9iKOC9tb3uLg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376) (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Jan 6, 2017 at 11:06 AM, Andres Freund <andres@anarazel.de> wrote: > On 2017-01-06 11:01:32 -0500, Robert Haas wrote: >> On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund <andres@anarazel.de> wrote: >> > On 2016-12-16 09:34:31 -0800, Andres Freund wrote: >> >> > To fix his issue, we need something like your 0001. Are you going to >> >> > polish that up soon here? >> >> >> >> Yes. >> > >> > I've two versions of a fix for this. One of them basically increases the >> > "spread" of buckets when the density goes up too much. It does so by >> > basically shifting the bucket number to the left (e.g. only every second >> > bucket can be the "primary" bucket for a hash value). The other >> > basically just replaces the magic constants in my previous POC patch >> > with slightly better documented constants. For me the latter works just >> > as well as the former, even though aesthetically/theoretically the >> > former sounds better. I'm inclined to commit the latter, at least for >> > now. >> >> Did you intend to attach the patches? > > No, I hadn't. You're interested in the "spreading" version? I honestly have no opinion. If you're confident that you know what you want to do, it's fine with me if you just do it. If you want my opinion I probably need to see both patches and compare. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: