On Sat, Jan 7, 2012 at 9:31 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote:
> Anyway, here's a new version of the patch. It no longer busy-waits for > in-progress insertions to finish, and handles xlog-switches. This is now > feature-complete. It's a pretty complicated patch, so I would appreciate > more eyeballs on it. And benchmarking again. Took me awhile to understand why the data structure for the insertion slots is so complex. Why not have slots per buffer? That would be easier to understand and slots are very small. Not sure if its a good idea, but we should explain the design options around that choice. Can we avoid having spinlocks on the slots altogether? If we have a page number (int) and an LSN, inserters would set LSN and then set page number. Anybody waiting for slots would stop if page number is zero since that means its not complete yet. So readers look at page number first and aren't allowed to look at LSN without valid page number. Page number would be useful in working out where to stop when doing background flushes, which we need for Group Commit, which is arriving soon for this release. Can we also try aligning the actual insertions onto cache lines rather than just MAXALIGNing them? The WAL header fills half a cache line as it is, so many other records will fit nicely. I'd like to see what that does to space consumption, but it might be a useful option at least. I'd like to see test results with FPWs turned off and CACHEALIGNed inserts. Again, we're planning on avoiding FPWs in future, so it would be sensible to check the tuning in that configuration also. GetInsertRecPtr() should return the XLogRecPtr of the latest allocation. IMHO that is what we need for checkpoints and the walsender doesn't really matter. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers