Beena Emerson
memis****@gmail*****
2013年 10月 1日 (火) 14:23:01 JST
On Wed, Aug 21, 2013 at 4:22 PM, Fujii Masao <masao****@gmail*****> wrote: > Thanks to this patch, the fast-path seems to be more likely to be > executed. So I think it's better to improve CPBIGM() which is > executed in the fast-path. What I'm thinking is to change CPBIGM() > as CPTRGM(), i.e., > > #define CPBIGM(a,b) do { \ > *(((char*)(a))+0) = *(((char*)(b))+0); \ > *(((char*)(a))+1) = *(((char*)(b))+1); \ > bptr->bytelen = len; \ > bptr->pmatch = false; \ > } while(0); > > and then move what CPBIGM() is now doing to compact_bigram(). > > I'm not sure whether the above change really increase the performance, > but it seems to be worth trying that because avoiding memcpy() > basically gives us better performance. Of course, performance test > is required before applying the patch, though. Thought? > The attached patch edits the CPBIGM and compact_bigram code as discussed. I performed some pgbench tests with custom queries on table with around 2MB data and found that there was around 5% increase in throughput after the patch was applied. Scenario 1: Vanilla pg_bigm Scenario 2: pg_bigm with the attached patch applied. query1 : search string 'postgresql.conf' query2 : search string 'database' query3 : search string ' bigm' The following table gives the average tps (excl connection establishing) of four runs for each query in each scenario Average-> query1 query2 query3 Scenario 1: 51.80787 95.12354 492.0916 Scenario 2: 54.79781 100.8324 514.0516 % increase 5.77 6.0 4.46 Beena Emerson -------------- next part -------------- HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...다운로드 -------------- next part -------------- $B%F%-%9%H7A<00J30$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B... $B%U%!%$%kL>(B: change_CPBIGM.patch $B7?(B: application/octet-stream $B%5%$%:(B: 875 $B%P%$%H(B $B ＠ bL@(B: $BL5$7(B URL: http://lists.sourceforge.jp/mailman/archives/pgbigm-hackers/attachments/20131001/5b79b45a/attachment.obj
Fork