To try it out, download the updated binary, unpack it, create a new database instance using
bin/hyperdb --initdb mydatabase
And start the database server (note that you need to add -i is you plan to use TCP, for example for the JDBC driver)
bin/hyperdb mydatabase
Now we can connect using the regular PostgerSQL tools, for example by using
psql -h /tmp -p 7483
The PostgreSQL wire protocol emulation is still relatively new, but it should be usable already. Please send us a note if you encounter bugs or missing features.
A more detailed description of how to use that setup together with the DBT-3 setup can be found here. We had to fix some bugs in the original DBT-3 release to get it running, but now we can run nearly exactly the same benchmark script in PostgrSQL and HyPer (we are working on fixing the remaining issues).
Of course while we want to emulate the PostgreSQL interface for compatibility reasons, the actual implementation is completely different. We have some performance numbers for SF-10 on PostgreSQL and on HyPer online, and the composite score of HyPer is roughly a factor 45 better than the score of PostgreSQL.
Hi, do you have the demo binary compiled for Windows? I would like to compare HyPer with SQL Server (which runs only on Windows) on the same machine. Thank you.
ReplyDeleteWe currently do not support Windows. Our main development platform is Linux, from time to time we also test on FreeBSD and OS X. Windows is quite a bit different from these POSIX-ish platforms, we not not have a working port yet.
DeleteHi Thomas,
ReplyDeleteI wasn't able to run the demo under OSX, I got: cannot execute binary file.
Here's the command: ./hyper_initdb -D /usr/local/hyperdb/data
./hyper_initdb: line 31: /usr/local/hyperdb/bin/hyperd: cannot execute binary file
Unfortunately the binary is for 64bit Linux, you cannot execute it on OS X. We have done OS X builds in the past, but currently we primarily develop using Linux.
DeleteI also get an error:
ReplyDelete```./bin/driver: relocation error: /home/carli/sources/hyperdemo/bin/../lib/librt.so.1: symbol __vdso_clock_gettime, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
```
This is a glibc compatibility issue. Most likely you can fix it by simply deleting librt.so* from the lib directory. We bundled librt out of paranoia, but we then found that bundling it created some compatibility issues on some Linux distributions. Your system librt should work fine.
Delete