i believe the last submission of the patch had no negative performance impact on any of the tested use cases, but you'd have to go back and see the last exchange on that.

i think it was the concern about potentially regressing the codeline in unforeseen ways without a clear benefit to all but one use case (wide tables) that stalled things.

From: Josh Berkus <josh@agliodbs.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>; Amit Kapila <amit.kapila@huawei.com>; Andres Freund <andres@2ndquadrant.com>; Craig Ringer <craig@2ndquadrant.com>; Jameison Martin <jameisonb@yahoo.com>; Noah Misch <noah@leadboat.com>; Kevin Grittner <kgrittn@mail.com>; robertmhaas@gmail.com; pgsql-hackers@postgresql.org
Sent: Monday, June 24, 2013 10:32 PM
Subject: Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

I think its rather a shame that the proponents of this patch have
tried so hard to push this through without working variations on the
theme. Please guys, go away and get creative; rethink the approach so
that you can have your lunch without anybody else losing theirs. I
would add that I have seen the use case and want to support it, but
we're looking to add to the codebase not just steal small bites of
performance from existing use cases.
Do we really have ironclad numbers which show that the patch affects
performance negatively?  I didn't think the previous performance test
was comprehensive; I was planning to develop one myself this week.

Josh Berkus
PostgreSQL Experts Inc.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 38 of 52 | next ›
Discussion Overview
grouppgsql-hackers @
postedOct 13, '12 at 7:56a
activeAug 22, '13 at 12:40a



site design / logo © 2021 Grokbase