On Fri, 18 Apr 2008, Tom Lane wrote:
> Yeah, it's starting to be obvious that we'd better not ignore sysbench
> as "not our problem". Do you have any roadmap on what needs to be done
> to it?
Just dug into this code again for a minute and it goes something like
this:
1) Wrap the write statements into transactions properly so the OLTP code
works. There's a BEGIN/COMMIT in there, but last time I tried that test
it just deadlocked on me (I got a report of the same from someone else as
well). There's some FIXME items in the code for PostgreSQL already that
might be related here.
2) Make sure the implementation is running statistics correctly (they
create a table and index, but there's certainly no ANALYZE in there).
3) Implement the part of the driver wrapper that haven't been done yet.
4) Try to cut down on crashes (I recall a lot of these when I tried to use
all the features).
5) Compare performance on some simple operations to pgbench to see if it's
competitive. Look into whether there's code in the PG wrapper they use
that can be optimized usefully.
There's two performance-related things that jump right out as things I'd
want to confirm aren't causing issues:
-It's a threaded design
-The interesting tests look like they use prepared statements.
I think the overall approach sysbench uses is good, it just needs some
adjustments to work right against a PG database.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
