Re: Patch: Optimize memory allocation in function 'bringetbitmap' - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Patch: Optimize memory allocation in function 'bringetbitmap'
Date
Msg-id 20150927175608.GM295765@alvherre.pgsql
Whole thread Raw
In response to Patch: Optimize memory allocation in function 'bringetbitmap'  ("Jinyu Zhang" <beijing_pg@163.com>)
Responses Re: Patch: Optimize memory allocation in function 'bringetbitmap'  (zhangjinyu <beijing_pg@163.com>)
List pgsql-hackers
Jinyu Zhang wrote:
> 
> BRIN Scan: Optimize memory allocation in function 'bringetbitmap'.
> We can allocate memory for some pointer before do long loop instead of allocating
> memory in long loop.
> 
> Before optimizing code (warm run)
> postgres=# select count(*) from lineitem where l_orderkey=1;
> Time: 456.219 ms
> 
> After optimizing code (warm run)
> postgres=# select count(*) from lineitem where l_orderkey=1;
> Time: 349.219 ms

Hmm, did you measure this in a c-assert-enabled build?  Those are slower
in allocation because of the memory-clobber thingy; without that, the
allocations would be a lot faster, so perhaps the gains are not so
interesting.  Still, it's a lot of palloc/pfree calls that do not happen
with your patch, so perhaps it's still worthwhile, but please do measure
it.

However I wonder if it would be simpler to have the dtup structure have
the pointers, so that you can pass it as NULL in the first call and then
followup calls reuse the one allocated in the first call.  That makes
the callers a bit less ugly, I think.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump LOCK TABLE ONLY question
Next
From: Jeff Janes
Date:
Subject: Building with MinGW