Prev: pg_stop_backup does not complete
Next: pgsql: Move documentation of all recovery.conf option to a new chapter.
From: Robert Haas on 23 Feb 2010 13:20
On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian <bruce(a)momjian.us> wrote:
> Tom Lane wrote:
>> Jeremy Kerr <jk(a)ozlabs.org> writes:
>> > Stephen,
>> >> If the updated function is always faster when the overall string is at
>> >> least, say, 16 characters long,
>>
>> > But that's not the case - the cost of the function (and the speedup from
>> > the previous version) depends on the number of spaces that there are at
>> > the end.
>>
>> Right, but there are certainly not more spaces than there are string
>> characters ;-)
>>
>> I think Dimitri's idea is eminently worth trying.  In a string of less
>> than, say, 16 bytes, the prospects of being able to win anything get
>> much smaller compared to the prospects of wasting the extra loop
>> overhead.  There is also a DBA psychology angle to it.  If you've got
>> CHAR(n) for very small n, it's likely that the type is being used in the
>> "canonical" fashion and there won't be many trailing blanks.  The case
>> where we can hope to win is where we have CHAR(255) or some other
>> plucked-from-the-air limit.
>
> What ever happened to this patch?

I think it's unclear that all of the best and worst cases have been
sufficiently tested and that the results are satisfactory. We have
everything from massive performance gains to no obvious benefit at
all, and it's very unclear that anyone has made a serious effort to
find a benchmark the worst-case scenarios. I think we should drop
this for now. *If* someone wants to put some work into more thorough
analysis for 9.1, we can revisit it then.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alvaro Herrera on 23 Feb 2010 13:23
Robert Haas escribi�:
> On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian <bruce(a)momjian.us> wrote:

> > What ever happened to this patch?
>
> I think it's unclear that all of the best and worst cases have been
> sufficiently tested and that the results are satisfactory. We have
> everything from massive performance gains to no obvious benefit at
> all, and it's very unclear that anyone has made a serious effort to
> find a benchmark the worst-case scenarios. I think we should drop
> this for now. *If* someone wants to put some work into more thorough
> analysis for 9.1, we can revisit it then.

+1 -- it's not like it hasn't been a problem all along.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Stefan Kaltenbrunner on 23 Feb 2010 13:29
Alvaro Herrera wrote:
> Robert Haas escribi�:
>> On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian <bruce(a)momjian.us> wrote:
>
>>> What ever happened to this patch?
>> I think it's unclear that all of the best and worst cases have been
>> sufficiently tested and that the results are satisfactory. We have
>> everything from massive performance gains to no obvious benefit at
>> all, and it's very unclear that anyone has made a serious effort to
>> find a benchmark the worst-case scenarios. I think we should drop
>> this for now. *If* someone wants to put some work into more thorough
>> analysis for 9.1, we can revisit it then.
>
> +1 -- it's not like it hasn't been a problem all along.

hmm I tend to disagree, this patch was specifically done to address a
hotspot I noticed under a given workload and it helped a lot for that
workload(like getting 6000qps more is pretty neat imho).
While people might not use fixed width chars that often(which especially
for migrated database is imho not true) it is an issue that can be seen
with a rather popular database related benchmarking tool so we should
not really dismiss it easily.


Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 23 Feb 2010 13:39
Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> writes:
> hmm I tend to disagree, this patch was specifically done to address a
> hotspot I noticed under a given workload and it helped a lot for that
> workload(like getting 6000qps more is pretty neat imho).
> While people might not use fixed width chars that often(which especially
> for migrated database is imho not true) it is an issue that can be seen
> with a rather popular database related benchmarking tool so we should
> not really dismiss it easily.

Nobody suggested dismissing it. The point was that it hasn't been
tested adequately to justify applying it now.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Stefan Kaltenbrunner on 23 Feb 2010 13:42
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> writes:
>> hmm I tend to disagree, this patch was specifically done to address a
>> hotspot I noticed under a given workload and it helped a lot for that
>> workload(like getting 6000qps more is pretty neat imho).
>> While people might not use fixed width chars that often(which especially
>> for migrated database is imho not true) it is an issue that can be seen
>> with a rather popular database related benchmarking tool so we should
>> not really dismiss it easily.
>
> Nobody suggested dismissing it. The point was that it hasn't been
> tested adequately to justify applying it now.

not sure what testing people want to get done though (there are a fair
amount of results and profiles in the thread)?


Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2
Prev: pg_stop_backup does not complete
Next: pgsql: Move documentation of all recovery.conf option to a new chapter.