pgaddict

40 ms·

361.
by pgaddict 12y ago
In my experience the wisdom "GIN is slower to update than GiST" is mostly obsolete nowadays. At least that's what my benchmark results suggest http://blog.pgaddict.com/posts/performance-since-postgresql-.
362.
by pgaddict 12y ago
FWIW, I just posted the next part, comparing performance with analytical workloads (TPC-DS-like, DWH/DSS, ...). http://blog.pgaddict.com/posts/performance-since-postgresql-...
363.
by pgaddict 12y ago
Because that's pretty much what he says in his post to comp.compression, where he announces that someone accepted the challenge. Let me quote: > Before naming the individual and giving additional details of our > correspondence,
364.
by pgaddict 12y ago
It's not just about removing support for hardware - that happens from time to time, but generally not with reasonably recent hardware. It's also about minimizing risk of bugs in the new parts - even if you do a very thorough testi
365.
by pgaddict 12y ago
IMHO the assumption that parsing the SQL is the bottleneck here is unfounded - I'd like to see some analysis supporting that first. The queries used in those benchmarks are extremely trivial, and there are far more expensive operations
366.
by pgaddict 12y ago
Different distributions for different users/customers, I guess. People who run RH often require stability over long periods of time, but if you want faster update cycle, RH (or derived distros) might not be the right choices. Hmmm, but
367.
by pgaddict 12y ago
PostgreSQL stores the data in a different way (each object gets a different file, or several files), so extending the size of tablespace files is not a big issue and dropping objects is as simple as deleting the file. The LRU is basically t
368.
by pgaddict 12y ago
You mean how the transaction rate changes when things like checkpoint or vacuum are triggered in the background? Yeah, I do have those numbers, and the consistency improved a lot (especially when autovacuum was introduced in 8.1, and when s
369.
by pgaddict 12y ago
Well, you're right. The thing is - it's the kernel version for that particular distribution, tracking RH 6. That's one of the reasons why I did the tests on the Gentoo box with a much newer kernel.
370.
by pgaddict 12y ago
Good point. For example the 9.2 changes were done after in-kernel lseek() optimizations, which improved the performance in some workloads. So yes, that might be a factor here (and I should have point that out in the post). I can't easi
371.
by pgaddict 12y ago
Actually, if there's someone with MySQL (or MariaDB) tuning skills, it'd be interesting to do a proper comparison. Might be a nice conference talk too, so let me know.
372.
by pgaddict 12y ago
Exactly.
373.
by pgaddict 12y ago
That'd be an interesting benchmark, but I don't have the MySQL expertise to do that (and I don't want to publish bullshit results).
374.
by pgaddict 12y ago
Good question. It was mentioned in the talk ( http://www.slideshare.net/fuzzycz/performance-archaeology-40... ), but I forgot to put that into the post. Both machines were running Linux. The DL380 machine (the 'main
375.
by pgaddict 12y ago
I was considering that when writing that post, but that'd be a much longer post, especially if I was to explain the logic behind the changes. And without that, it's be just a list of release notes, so not really useful IMHO. That&