I really should have prefaced this with my personal schtick about benchmarks. Benchmarks divorced of context are good only as a point of interest. A starting off point for more meaningful benchmarks. I wouldn't pick a technology based off of this, unless the project was just to throw hashes at a database and then pull them back out without using them for anything. I just thought it was an entertaining exercise in between more productive matters :P
The table was running in memory, though it was still logging. Given that the pg gem seems to be largely a wrapper for c extensions to postgres' drivers, I probably should have used hiredis. Honestly didn't think about. Thanks for the tip :) On Wednesday, June 27, 2012 1:00:14 PM UTC-7, Matt Aimonetti wrote: > > You should also really use hiredis, it will make a huge performance > difference. The other thing to keep in mind is that with redis, you might > want to pipeline multiple writes writes at once. > Finally, Postgres has to parse the SQL query which is more expensive than > reading the binary protocol used by Redis. > > But, in all honestly, I wouldn't pick a technology simply based on these > kind of benchmarks ;) > > - Matt > > On Wed, Jun 27, 2012 at 11:51 AM, Guyren Howe wrote: > >> On Jun 27, 2012, at 0:02 , Nathaniel Barnes wrote: >> >> > So after Guy's talk introduced me to postgres' hstore (thanks for that >> btw), I was curious to see what the performance difference between it and >> redis would be in serializing objects. A couple of others at the meeting >> expressed some interest in it and I finally got some spare time to throw >> together a script to get some results. So with that in mind, here's the >> quick script I wrote, and the results it generated. >> > >> > https://gist.github.com/3001890 >> > >> > Not sure what's with that massive spike with selects from postgres at >> 10,000 selects. I figure most likely my macbook just ran out of memory or >> some such. I should likely try this again in an EC2 instance for giggles. >> That being said, the base key/value store is clearly faster, which was >> largely expected since it doesn't have to deal with any of the normal >> relational overhead. However that also means you don't get all that >> delicious relational overhead. >> > >> > Just thought I'd share with everyone :) >> >> This is great, thanks! >> >> The obvious question is whether Postgres was configured to work similarly >> to Redis. That would mostly mean using an unlogged table in a RAM disk. >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby >> > > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
