Re: [HACKERS] Misaligned BufferDescriptors causing major performance problems on AMD
On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote: master + 32align.patch: -c max_connections=400 tps = 183791.872359 (high run vs. run variability) -c max_connections=401 tps = 185494.98244 (high run vs. run variability) master + 64align.patch: -c max_connections=400 tps = 489257.195570 -c max_connections=401 tps = 490496.520632 Pretty much as expected, rigth? Yes, I am convinced. Let's work on a patch now. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New CF app deployment
On Mon, Jan 26, 2015 at 3:24 PM, Magnus Hagander mag...@hagander.net wrote: Yes, and the agreement after that feedback was to try it out and then figure out what changes were needed? As about half the feedback said it was better without and half said it was better with. Well, I can't speak to anyone else's opinion, but I'm quite sure I raised the issue that we need a way to call out which messages in the thread are important, and I think that's pretty much what Peter is saying, too. I find the new tool essentially unusable - having one link to the whole thread instead of individual links to just the important messages in that thread is a huge regression for me, as is the lack of the most recent activity on the summary page. I don't know how much more feedback than that you need to be convinced, but I'm going to shut up now before I say something I will later regret. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: plpgsql - Assert statement
On 1/22/15 2:01 PM, Pavel Stehule wrote: * I would to simplify a behave of evaluating of message expression - probably I disallow NULL there. Well, the only thing I could see you doing there is throwing a different error if the hint is null. I don't see that as an improvement. I'd just leave it as-is. I enabled a NULL - but enforced a WARNING before. I don't see the separate warning as being helpful. I'd just do something like +(err_hint != NULL) ? errhint(%s, err_hint) : errhint(Message attached to failed assertion is null) )); There should also be a test case for a NULL message. * GUC enable_asserts will be supported That would be good. Would that allow for enabling/disabling on a per-function basis too? sure - there is only question if we develop a #option enable|disable_asserts. I have no string idea. The option would be nice, but I don't think it's strictly necessary. The big thing is being able to control this on a per-function basis (which I think you can do with ALTER FUNCTION SET?) -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
