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_se
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 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
> > > th
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
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 maste
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 poi
