On Mon, Jun 30, 2014 at 11:08 PM, Beena Emerson <memissemer...@gmail.com> wrote: > > I also ran the test script after making the same configuration changes that > you have specified. I found that I was not able to get the same performance > difference that you have reported. > > Following table lists the tps in each scenario and the % increase in > performance. > > Threads Head Patched Diff > 1 1669 1718 3% > 2 2844 3195 12% > 4 3909 4915 26% > 8 7332 8329 14% >
coming back to this old thread.
I just tried a new approach for this priority table, instead of a
entirely separate buffer pool,
Just try to use a some portion of shared buffers to priority tables
using some GUC variable
"buffer_cache_ratio"(0-75) to specify what percentage of shared
buffers to be used.
Syntax:
create table tbl(f1 int) with(buffer_cache=true);
Comparing earlier approach, I though of this approach is easier to implement.
But during the performance run, it didn't showed much improvement in
performance.
Here are the test results.
Threads Head Patched Diff
1 3123 3238 3.68%
2 5997 6261 4.40%
4 11102 11407 2.75%
I am suspecting that, this may because of buffer locks that are
causing the problem.
where as in older approach of different buffer pools, each buffer pool
have it's own locks.
I will try to collect the profile output and analyze the same.
Any better ideas?
Here I attached a proof of concept patch.
Regards,
Hari Babu
Fujitsu Australia
cache_table_poc.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
