Tomas Vondra wrote:
> 1) bringetbitmap(PG_FUNCTION_ARGS)
>
> + /*
> + * Estimate the approximate size of btup and allocate memory for btup.
> + */
> + btupInitSize = bdesc->bd_tupdesc->natts * 16;
> + btup = palloc(btupInitSize);
>
> What is the reasoning behind this estimate? I mean, this onl
David Steele wrote:
> On 3/4/17 12:43 AM, Robert Haas wrote:
> > I think we should regard this resubmission as untimely, unless there
> > is an argument that it amounts to a bug fix.
>
> I agree and I'm also confused about which author this is waiting on. Is
> it Jinyu or Álvaro?
I don't think
On 3/4/17 12:43 AM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 11:28 PM, Alvaro Herrera
> wrote:
>> Alvaro Herrera wrote:
>>> Jinyu Zhang wrote:
>>>
Update the patch_brin_optimze_mem according to your comment.
>>>
>>> I have added this patch to the commitfest, which I've been intending to
>>
On Wed, Mar 1, 2017 at 11:28 PM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>> Jinyu Zhang wrote:
>>
>> > Update the patch_brin_optimze_mem according to your comment.
>>
>> I have added this patch to the commitfest, which I've been intending to
>> get in for a long time. I'll be submitting an
Alvaro Herrera wrote:
> Jinyu Zhang wrote:
>
> > Update the patch_brin_optimze_mem according to your comment.
>
> I have added this patch to the commitfest, which I've been intending to
> get in for a long time. I'll be submitting an updated patch soon.
Here it is. I addressed some of Tomas' c
Jinyu Zhang wrote:
>
>
> Update the patch_brin_optimze_mem according to your comment.
I have added this patch to the commitfest, which I've been intending to
get in for a long time. I'll be submitting an updated patch soon.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Postgr
On Tue, Dec 15, 2015 at 10:41 AM, Tomas Vondra
wrote:
> On 10/16/2015 08:00 PM, Jinyu Zhang wrote:
>> Update the patch_brin_optimze_mem according to your comment.
>
> I've reviewed the last version of the patch, and I do have a few comments. I
> haven't done any performance testing at this point,
Hi,
On 10/16/2015 08:00 PM, Jinyu Zhang wrote:
Update the patch_brin_optimze_mem according to your comment.
I've reviewed the last version of the patch, and I do have a few
comments. I haven't done any performance testing at this point, as the
machine I'm using for that is chewing on someth
Update the patch_brin_optimze_mem according to your comment.
At 2015-10-16 10:13:35, "Alvaro Herrera" wrote:
>zhangjinyu wrote:
>
>> 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
Also, please make sure your patch is registered in
https://commitfest.postgresql.org/7/ so that we don't forget.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hack
zhangjinyu wrote:
> 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.
> Jinyu: the memory is allocated from perRangeCxt and per
Yes, I forgot disable-c-assert last test.
The following show the test result when disable-c-assert.
I think it's still worthwhile.
*After optimize code (warm run)*
postgres=# select count(*) from lineitem where l_orderkey=1;
count
---
6
(1 row)
Time: 327.143 ms
*Before optimizing cod
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
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;
count
---
6
(1 row)
14 matches
Mail list logo