Fujii Masao
masao****@gmail*****
2013年 10月 2日 (水) 22:54:53 JST
On Tue, Oct 1, 2013 at 11:47 PM, Fujii Masao <masao****@gmail*****> wrote: > On Tue, Oct 1, 2013 at 2:23 PM, Beena Emerson <memis****@gmail*****> wrote: >> 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 > > Thanks for the patch! I also will do the benchmark! I could not see any performance improvement by the patch in the benchmark... Could you let me know how you did the benchmark? Regards, -- Fujii Masao
Fork