Robert Haas writes:
> On Sat, Jul 31, 2010 at 12:32 PM, Tom Lane wrote:
>> So it'd definitely be a lot better than now. Maybe there'd be some
>> remaining performance gap for non-pathological cases, but I think we
>> would be willing to pay that in order to avoid bad behavior for the
>> patholog
Robert Haas writes:
> On Sat, Jul 31, 2010 at 12:32 PM, Tom Lane wrote:
>> So it'd definitely be a lot better than now. Maybe there'd be some
>> remaining performance gap for non-pathological cases, but I think we
>> would be willing to pay that in order to avoid bad behavior for the
>> patholog
On Sat, Jul 31, 2010 at 12:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 31, 2010 at 12:02 PM, Tom Lane wrote:
>>> I'm tempted to suggest that making RBNode be a hidden struct containing
>>> a pointer to somebody else's datum is fundamentally the wrong way to
>>> go about things, b
Robert Haas writes:
> On Sat, Jul 31, 2010 at 12:02 PM, Tom Lane wrote:
>> I'm tempted to suggest that making RBNode be a hidden struct containing
>> a pointer to somebody else's datum is fundamentally the wrong way to
>> go about things, because the extra void pointer is pure overhead,
>> and we
On Sat, Jul 31, 2010 at 12:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 31, 2010 at 12:40 AM, Tom Lane wrote:
>>> So, I would like somebody to show cause why that whole module shouldn't
>>> be ripped out and the code reverted to where it was in 8.4. My
>>> recollection is that th
Robert Haas writes:
> On Sat, Jul 31, 2010 at 12:40 AM, Tom Lane wrote:
>> So, I would like somebody to show cause why that whole module shouldn't
>> be ripped out and the code reverted to where it was in 8.4. My
>> recollection is that the argument for adding it was to speed things up
>> in cor
On Sat, Jul 31, 2010 at 12:40 AM, Tom Lane wrote:
> Another misbehavior that I noted while playing with Artur's example is
> that, while GIN index build seems to adhere pretty well to whatever
> maintenance_work_mem limit you give it in 8.4, it blows right by that
> limit in 9.0 and HEAD --- I obs
Another misbehavior that I noted while playing with Artur's example is
that, while GIN index build seems to adhere pretty well to whatever
maintenance_work_mem limit you give it in 8.4, it blows right by that
limit in 9.0 and HEAD --- I observed it happily eating something north
of 128MB with a mai
