Re: Parallel bitmap index scan

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel bitmap index scan
Date: 2020-12-23 02:59:52
Message-ID: CAFiTN-t2h8tmQxjgiXHWCm-CTB6cqJGcCV35G+LrXK6A_Y0_9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 23 Dec 2020 at 4:15 AM, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
wrote:

> On 11/11/20 8:52 PM, Tomas Vondra wrote:
> > Hi,
> >
> > I took a look at this today, doing a bit of stress-testing, and I can
> > get it to crash because of segfaults in pagetable_create (not sure if
> > the issue is there, it might be just a symptom of an issue elsewhere).
> >
> > Attached is a shell script I use to run the stress test - it's using
> > 'test' database, generates tables of different size and then runs
> > queries with various parameter combinations. It takes a while to trigger
> > the crash, so it might depend on timing or something like that.
> >
> > I've also attached two examples of backtraces. I've also seen infinite
> > loop in pagetable_create, but the crashes are much more common.
> >
>
> Hi Dilip,
>
> Do you plan to work on this for PG14? I haven't noticed any response in
> this thread, dealing with the crashes I reported a while ago. Also, it
> doesn't seem to be added to any of the commitfests.

Hi Tomas,

Thanks for testing this. Actually we have noticed a lot of performance
drop in many cases due to the tbm_merge. So off list we are discussing
different approaches and testing the performance. So basically, in the
current approach all the worker are first preparing their bitmap hash and
then they are merging into the common bitmap hash under a lock. So based
on the off list discussion with Robert, the next approach I am trying is to
directly insert into the shared bitmap hash while scanning the index
itself. So now instead of preparing a separate bitmap, all the workers
will directly insert into the shared bitmap hash. I agree that for getting
each page from the bitmaphash we need to acquire the lock and this also
might generate a lot of lock contention but we want to try the POC and
check the performance. In fact I have already implemented the POC and
results aren't great. But I am still experimenting with it to see whether
the lock can be more granular than I have now. I will share my finding
soon along with the POC patch.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hou, Zhijie 2020-12-23 03:44:30 RE: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW
Previous Message Bruce Momjian 2020-12-23 02:58:18 Re: Proposed patch for key managment