Pavel Stehule pavel.steh...@gmail.com writes:
[ numeric-optimize-v8.patch ]
I've committed this with some adjustments. Aside from cosmetic
changes and documentation/comment improvements:
* I don't agree at all with the claim that aggtransspace is only useful
for INTERNAL transition data.
On 24.9.2013 17:57, Pavel Stehule wrote:
2013/9/24 Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com
On Mon, Sep 23, 2013 at 4:15 PM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
Seems ready for commiter to me. I'll wait a few days for others
to comment, and
On Mon, Sep 23, 2013 at 4:15 PM, Tomas Vondra t...@fuzzy.cz wrote:
Seems ready for commiter to me. I'll wait a few days for others to
comment, and then I'll update the commitfest page.
Some thoughts:
The documentation doesn't reflect the restriction to type internal.
On a related note, why
On 23 Září 2013, 18:18, Pavel Stehule wrote:
Hello
2013/9/22 Tomas Vondra t...@fuzzy.cz
Hi,
I've reviewed the v6 of the numeric optimize patch
(http://www.postgresql.org/**message-id/**CAFj8pRDQhG7Pqmf8XqXY0PnHfakkP**
Hi,
I've reviewed the v6 of the numeric optimize patch
(http://www.postgresql.org/message-id/CAFj8pRDQhG7Pqmf8XqXY0PnHfakkPQLPHnoRLJ_=ekfsboa...@mail.gmail.com),
as Pavel did some hacking on the patch and asked me to do the review.
The patch seems fine to me, the following comments are mostly
On 7/8/13 10:05 AM, Pavel Stehule wrote:
I am testing your code, and It increase speed of sum about 24% faster
then original implementation.
This patch needs to be rebased (and/or the later version registered in
the commit fest).
--
Sent via pgsql-hackers mailing list
2013/9/4 Peter Eisentraut pete...@gmx.net
On 7/8/13 10:05 AM, Pavel Stehule wrote:
I am testing your code, and It increase speed of sum about 24% faster
then original implementation.
This patch needs to be rebased (and/or the later version registered in
the commit fest).
I updated a
On 9/4/13 2:26 PM, Pavel Stehule wrote:
2013/9/4 Peter Eisentraut pete...@gmx.net mailto:pete...@gmx.net
On 7/8/13 10:05 AM, Pavel Stehule wrote:
I am testing your code, and It increase speed of sum about 24% faster
then original implementation.
This patch needs to
Hello,
int, float, double 26829 ms (26675 ms) -- 0.5% slower .. statistic error ..
cleaner code
numeric sum 6490 ms (7224 ms) -- 10% faster
numeric avg 6487 ms (12023 ms) -- 46% faster
I also got very similar results.
On the other hand, initially I was receiving sigsegv's whenever I
wanted
2013/8/29 Hadi Moshayedi h...@moshayedi.net
Hello,
int, float, double 26829 ms (26675 ms) -- 0.5% slower .. statistic error
..
cleaner code
numeric sum 6490 ms (7224 ms) -- 10% faster
numeric avg 6487 ms (12023 ms) -- 46% faster
I also got very similar results.
On the other hand,
Hello
here is a rebased patch. Hadi, please, can verify this version?
Regards
Pavel
p.s. Performance tests
postgres=# create table foo(a int, b float, c double precision, d numeric,
gr int);
CREATE TABLE
postgres=#
postgres=# insert into foo select 1, 2.0, 3.0, 3.14, random()*1 from
2013/7/8 Hadi Moshayedi h...@moshayedi.net:
I am attaching the updated the patch, which also fixes a bug which
caused one of the regression tests failed.
I'll subscribe this patch to the commitfest in the next hour.
Can you please review the patch?
sure, :)
Pavel
Thanks,
-- Hadi
On 07/07/2013 09:14 PM, Hadi Moshayedi wrote:
I am attaching the updated the patch, which also fixes a bug which
caused one of the regression tests failed.
I'll subscribe this patch to the commitfest in the next hour.
Can you please review the patch?
I'm afraid that, since this patch
Hello
2013/7/8 Josh Berkus j...@agliodbs.com:
On 07/07/2013 09:14 PM, Hadi Moshayedi wrote:
I am attaching the updated the patch, which also fixes a bug which
caused one of the regression tests failed.
I'll subscribe this patch to the commitfest in the next hour.
Can you please review the
Pavel,
sure, it should be in September CF. It is relative simple patch
without global impacts. But I like it, it increase speed for
sum(numeric) about 25% and avg(numeric) about 50%
Do you think you could give this a review after CF1 ends, but before
September? I hate to make Hadi wait
2013/7/8 Josh Berkus j...@agliodbs.com:
Pavel,
sure, it should be in September CF. It is relative simple patch
without global impacts. But I like it, it increase speed for
sum(numeric) about 25% and avg(numeric) about 50%
Do you think you could give this a review after CF1 ends, but before
Hello
2013/3/20 Hadi Moshayedi h...@moshayedi.net:
Hi Tom,
Tom Lane t...@sss.pgh.pa.us wrote:
After thinking about that for awhile: if we pursue this type of
optimization, what would probably be appropriate is to add an aggregate
property (stored in pg_aggregate) that allows direct
Hello
2013/3/19 Tom Lane t...@sss.pgh.pa.us:
I wrote:
[ looks at patch... ] Oh, I see what's affecting the plan: you changed
the aggtranstypes to internal for a bunch of aggregates. That's not
very good, because right now the planner takes that to mean that the
aggregate could eat a lot of
Hi Tom,
Tom Lane t...@sss.pgh.pa.us wrote:
After thinking about that for awhile: if we pursue this type of
optimization, what would probably be appropriate is to add an aggregate
property (stored in pg_aggregate) that allows direct specification of
the size that the planner should assume for
Hello,
I updated the patch by taking ideas from your patch, and unifying the
transition struct and update function for different aggregates. The speed
of avg improved even more. It now has 60% better performance than the
current committed version.
This patch optimizes numeric/int8 sum, avg,
Hadi Moshayedi h...@moshayedi.net wrote:
I updated the patch by taking ideas from your patch, and unifying
the transition struct and update function for different
aggregates. The speed of avg improved even more. It now has 60%
better performance than the current committed version.
2013/3/19 Kevin Grittner kgri...@ymail.com:
Hadi Moshayedi h...@moshayedi.net wrote:
I updated the patch by taking ideas from your patch, and unifying
the transition struct and update function for different
aggregates. The speed of avg improved even more. It now has 60%
better performance
I am not sure how this works, but I also changed numeric sum(), and the
views in question had a numeric sum() column. Can that have any impact?
I am going to dig deeper to see why this happens.
On Tue, Mar 19, 2013 at 6:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com
[ please do not top-reply ]
Hadi Moshayedi h...@moshayedi.net writes:
On Tue, Mar 19, 2013 at 6:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh, what? Fooling around with the implementation of avg() should surely
not change any planning decisions.
I am not sure how this works, but I also
I wrote:
[ looks at patch... ] Oh, I see what's affecting the plan: you changed
the aggtranstypes to internal for a bunch of aggregates. That's not
very good, because right now the planner takes that to mean that the
aggregate could eat a lot of space. We don't want that to happen for
2013/3/16 Hadi Moshayedi h...@moshayedi.net:
Revisiting:
http://www.postgresql.org/message-id/45661be7.4050...@paradise.net.nz
I think the reasons which the numeric average was slow were:
(1) Using Numeric for count, which is slower than int8 to increment,
(2) Constructing/deconstructing
Hi Pavel,
Thanks a lot for your feedback.
I'll work more on this patch this week, and will send a more complete patch
later this week.
I'll also try to see how much is the speed up of this method for other
types.
Thanks,
-- Hadi
On Mon, Mar 18, 2013 at 10:36 AM, Pavel Stehule
Hello
I played with sum(numeric) optimization
Now it is based on generic numeric_add function - this code is
relative old - now we can design aggregates with internal transition
buffers, and probably we can do this work more effective.
I just removed useles palloc/free operations and I got a
Revisiting:
http://www.postgresql.org/message-id/45661be7.4050...@paradise.net.nz
I think the reasons which the numeric average was slow were:
(1) Using Numeric for count, which is slower than int8 to increment,
(2) Constructing/deconstructing arrays at each transition step.
This is also
Hello
2013/3/16 Hadi Moshayedi h...@moshayedi.net:
Revisiting:
http://www.postgresql.org/message-id/45661be7.4050...@paradise.net.nz
I think the reasons which the numeric average was slow were:
(1) Using Numeric for count, which is slower than int8 to increment,
(2)
30 matches
Mail list logo
