Hi,
On 2018-06-26 06:48:28 +0000, Ideriha, Takeshi wrote:
> > I think it would be interested for somebody to build a prototype here
> > that ignores all the problems but the first and uses some
> > straightforward, relatively unoptimized locking strategy for the first
> > problem. Then benchmark it. If the results show that the idea has
> > legs, then we can try to figure out what a real implementation would
> > look like.
> > (One possible approach: use Thomas Munro's DHT stuff to build the shared cache.)
>
> I'm inspired by this comment and now developing a prototype (please see attached),
> but I haven't yet put cache structure on shared memory.
> Instead, I put dummy data on shared memory which is initialized at startup,
> and then acquire/release lock just before/after searching/creating catcache entry.
> I haven't considered relcache and catcachelist either.
> It is difficult for me to do everything at one time with right direction.
> So I'm trying to make small prototype and see what I'm walking on the proper way.
>
> I tested pgbench to compare master branch with my patch.
>
> 0) Environment
> - RHEL 7.4
> - 16 cores
> - 128 GB memory
>
> 1) Initialized with pgbench -i -s10
>
> 2) benchmarked 3 times for each conditions and got the average result of TPS.
> |master branch | prototype | proto/master (%)
> ------------------------------------------------------------------------------------
> pgbench -c48 -T60 -Msimple -S | 131297 |130541 |101%
> pgbench -c48 -T60 -Msimple | 4956 |4965 |95%
> pgbench -c48 -T60 -Mprepared -S |129688 |132538 |97%
> pgbench -c48 -T60 -Mprepared |5113 |4615 |84%
>
> This result seems to show except for prepared protocol with "not only SELECT" it didn't make much difference.
This seems like an pretty large regression to me. And that's an
extremely simplistic case, with tiny caches, and barely any changes to
the cache contents.
Greetings,
Andres Freund