On 24.01.2013 00:30, Andres Freund wrote:
Also, while the apply side surely isn't benchmarkable without any being
submitted, the changeset generation can very well be benchmarked.
A very, very adhoc benchmark:
-c max_wal_senders=10
-c max_logical_slots=10 --disabled for anything but logical
On 2013-01-28 11:59:52 +0200, Heikki Linnakangas wrote:
On 24.01.2013 00:30, Andres Freund wrote:
Also, while the apply side surely isn't benchmarkable without any being
submitted, the changeset generation can very well be benchmarked.
A very, very adhoc benchmark:
-c max_wal_senders=10
On 2013-01-24 13:28:18 +0200, Heikki Linnakangas wrote:
One random thing that caught my eye in the patch, I though I'd mention it
while I still remember: In heap_delete, you call heap_form_tuple() in a
critical section. That's a bad idea, because if it runs out of memory -
PANIC.
Good point,
On 2013-01-24 20:53:18 +0200, Heikki Linnakangas wrote:
That said (hah, you knew there would be a but ;-)), now that I see what
that looks like, I'm feeling that maybe it wasn't such a good idea after
all. It sounded like a fairly small patch that greatly reduces the overhead
in the master
On 2013-01-24 20:28:41 -0500, Bruce Momjian wrote:
On Fri, Jan 25, 2013 at 02:16:09AM +0100, Andres Freund wrote:
What I am afraid though is that it basically goes on like this in the
next commitfests:
* 9.4-CF1: no serious reviewer comments because they are busy doing
release work
*
On Fri, Jan 25, 2013 at 02:40:03AM +0100, Andres Freund wrote:
The problem with that is not only that it sucks huge amounts of energy
out of me and others but also that its very hard to really build the
layers/users above changeset extraction without being able to rely on
the interface
