On Sun, Apr 13, 2014 at 2:23 PM, Tom Lane wrote:
> * I also left out the table documenting which aggregates have this
> optimization. That's not the kind of thing we ordinarily document,
> and it seems inevitable to me that such a table would be noteworthy
> mostly for wrong/incomplete/obsolete i
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: 14 April 2014 06:23
> To: Dean Rasheed
> Cc: Florian Pflug; David Rowley; Kevin Grittner; Josh Berkus; Greg Stark;
> PostgreSQL-development
> Subject: Re: [HACKERS] [PATCH] Negative Transitio
On Apr13, 2014, at 20:23 , Tom Lane wrote:
> Dean Rasheed writes:
>> OK, I'm marking this ready for committer attention, on the
>> understanding that that doesn't include the invtrans_minmax patch.
>
> I've finished reviewing/revising/committing this submission.
Cool! Thanks!
> Some notes:
>
Dean Rasheed writes:
> OK, I'm marking this ready for committer attention, on the
> understanding that that doesn't include the invtrans_minmax patch.
I've finished reviewing/revising/committing this submission.
Some notes:
* I left out the EXPLAIN ANALYZE statistics, as I still feel that they'r
On Apr11, 2014, at 19:42 , Tom Lane wrote:
> Florian Pflug writes:
>> Yes, the idea had come up at some point during the review discussion. I
>> agree that it's only worthwhile if it works for state type internal - though
>> I think there ought to be a way to allow that. We could for example simp
Florian Pflug writes:
> Yes, the idea had come up at some point during the review discussion. I
> agree that it's only worthwhile if it works for state type internal - though
> I think there ought to be a way to allow that. We could for example simply
> decree that the initfunc's first parameter m
Dean Rasheed writes:
> On 10 April 2014 19:54, Tom Lane wrote:
>> So if we go with that terminology, perhaps these names for the
>> new CREATE AGGREGATE parameters:
>>
>> initfuncapplies to plain aggregation, mutually exclusive with
>> initcond
>> msfunc (or just mfunc?) forwar
On Apr11, 2014, at 19:04 , Tom Lane wrote:
> It strikes me that your second point
>
>> 2) It allows strict aggregates whose state type and input type aren't
>> binary coercible to return NULL if all inputs were NULL without any
>> special coding. As it stands today, this doesn't work wit
Florian Pflug writes:
> On Apr11, 2014, at 17:09 , Tom Lane wrote:
>> Basically, this comes down to a design judgment call, and my judgment
>> is differing from yours. In the absence of opinions from others,
>> I'm going to do it my way.
> Ok. Are you going to do the necessary changes, or shall
On Apr11, 2014, at 17:09 , Tom Lane wrote:
> Basically, this comes down to a design judgment call, and my judgment
> is differing from yours. In the absence of opinions from others,
> I'm going to do it my way.
Ok. Are you going to do the necessary changes, or shall I? I'm happy to
leave it to y
Florian Pflug writes:
> Which is why I feel that having two separate sets of transition functions
> and state types solves the wrong problem. If we find a way to prevent
> transition functions from being called directly, we'll shave a few cycles
> of quite a few existing aggregates, invertible or
On 10 April 2014 22:52, Tom Lane wrote:
> Dean Rasheed writes:
>> I was imagining that firsttrans would only be passed the first value
>> to be aggregated, not any previous state, and that it would be illegal
>> to specify both an initcond and a firsttrans function.
>
>> The forward transition fu
On Apr11, 2014, at 01:30 , Tom Lane wrote:
> Florian Pflug writes:
>> As for evidence - have you looked at the patch I posted? I'd be very
>> interested to know if it removes the performance differences you saw.
>
> (1) You can't really prove the absence of a performance issue by showing
> that
Florian Pflug writes:
> My argument is that is costs us more complexity to duplicate everything
> for the invertible case, *and* the result seems less flexible - not
> from the POV of aggregate implementations, but from the POV of future
> extensions.
[ shrug... ] You can argue against any featu
On Apr11, 2014, at 00:07 , Tom Lane wrote:
> Florian Pflug writes:
>> I still think you're getting ahead of yourselves here. The number of
>> aggregates which benefit from this is tiny SUM(int2,int4) and maybe
>> BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on 64-bit archs -
>> for the ot
Florian Pflug writes:
> I still think you're getting ahead of yourselves here. The number of
> aggregates which benefit from this is tiny SUM(int2,int4) and maybe
> BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on 64-bit archs -
> for the others, the state type is already pass-by-ref.
That
On Apr10, 2014, at 21:34 , Dean Rasheed wrote:
> On 10 April 2014 19:54, Tom Lane wrote:
>> So if we go with that terminology, perhaps these names for the
>> new CREATE AGGREGATE parameters:
>>
>> initfuncapplies to plain aggregation, mutually exclusive with
>> initcond
>> msfunc
Dean Rasheed writes:
> I was imagining that firsttrans would only be passed the first value
> to be aggregated, not any previous state, and that it would be illegal
> to specify both an initcond and a firsttrans function.
> The forward transition function would only be called for values after
> t
On Apr10, 2014, at 02:13 , Florian Pflug wrote:
> On Apr9, 2014, at 23:17 , Florian Pflug wrote:
>> On Apr9, 2014, at 21:35 , Tom Lane wrote:
>>> A quick test says that avg(int4)
>>> is about five percent slower than sum(int4), so that's the kind of hit
>>> we'd be taking on non-windowed aggrega
On 10 April 2014 19:54, Tom Lane wrote:
> Dean Rasheed writes:
>> On 10 April 2014 19:04, Tom Lane wrote:
>>> What about names for the invertible-aggregate infrastructure?
>>> I'm tempted to prefix "inv" to all the existing names, but then
>>> "invsfunc" means the alternate forward function ...
Dean Rasheed writes:
> On 10 April 2014 19:04, Tom Lane wrote:
>> What about names for the invertible-aggregate infrastructure?
>> I'm tempted to prefix "inv" to all the existing names, but then
>> "invsfunc" means the alternate forward function ... can we use
>> "invifunc" for the inverse transi
On 10 April 2014 19:04, Tom Lane wrote:
> Dean Rasheed writes:
>> On 10 April 2014 15:18, Tom Lane wrote:
>>> This idea of a separate firsttrans function is interesting but perhaps
>>> orthogonal to the current patch. Also, I don't quite understand how
>>> it would work for aggregates with null
Dean Rasheed writes:
> On 10 April 2014 15:18, Tom Lane wrote:
>> This idea of a separate firsttrans function is interesting but perhaps
>> orthogonal to the current patch. Also, I don't quite understand how
>> it would work for aggregates with null initvalues; don't you end up
>> with exactly t
On 10 April 2014 15:18, Tom Lane wrote:
> Dean Rasheed writes:
>> On 10 April 2014 01:13, Florian Pflug wrote:
>>> However, I still believe the best approach at this point is to just work
>>> on making int4_avg_accum faster. I still see no principal reason what it
>>> has to be noticeably slower
Dean Rasheed writes:
> On 10 April 2014 01:13, Florian Pflug wrote:
>> However, I still believe the best approach at this point is to just work
>> on making int4_avg_accum faster. I still see no principal reason what it
>> has to be noticeably slower - the only additional work it absolutely *has*
On Thu, Apr 10, 2014 at 9:55 AM, Tom Lane wrote:
> Florian Pflug writes:
> > I was (and still am) not in favour of duplicating the whole quadruple of
> > (state, initialvalue, transferfunction, finalfunction) because it seems
> > excessive. In fact, I believed that doing this would probably be g
On Thu, Apr 10, 2014 at 9:55 AM, Tom Lane wrote:
>
> > I'm pretty sure David Rowley did some benchmarking. The results should be
> > in this thread somewhere I think, but they currently evade me... Maybe
> David
> > can re-post, if he's following this...
>
> I saw benchmarks addressing window agg
On 10 April 2014 01:13, Florian Pflug wrote:
> Also, the *only* reason that SUM(int2|int4) cannot use int8 as it's
> transition type is that it needs to return NULL, not 0, if zero rows
> were aggregates. It might seems that it could just use int8 as state
> with initial value NULL, but that only
On 9 April 2014 22:55, Tom Lane wrote:
> Florian Pflug writes:
>> I was (and still am) not in favour of duplicating the whole quadruple of
>> (state, initialvalue, transferfunction, finalfunction) because it seems
>> excessive. In fact, I believed that doing this would probably be grounds for
>>
On Apr9, 2014, at 23:17 , Florian Pflug wrote:
> On Apr9, 2014, at 21:35 , Tom Lane wrote:
>> A quick test says that avg(int4)
>> is about five percent slower than sum(int4), so that's the kind of hit
>> we'd be taking on non-windowed aggregations if we do it like this.
>
> That's rather surpri
Florian Pflug writes:
> I was (and still am) not in favour of duplicating the whole quadruple of
> (state, initialvalue, transferfunction, finalfunction) because it seems
> excessive. In fact, I believed that doing this would probably be grounds for
> outright rejection of the patch, on the base o
On Apr9, 2014, at 20:20 , Tom Lane wrote:
> There was discussion upthread of providing
> two separate forward transition functions, but Florian argued that that
> would do nothing that you couldn't accomplish with a runtime check in
> the forward function. I think that's nonsense though, because
On Apr9, 2014, at 21:35 , Tom Lane wrote:
> As a quick check, I compared aggregation performance in HEAD, non-assert
> builds, with and without --disable-float8-byval on a 64-bit machine.
> So this tests replacing a pass-by-val transition datatype with a
> pass-by-ref one without any other changes
I wrote:
> ... an invertible aggregate may require a more
> complex transition state data structure --- in particular, if you're
> forced to go from a pass-by-value to a pass-by-reference data type, right
> there you are going to take a big hit in aggregate performance, and there
> is no way for th
Dean Rasheed writes:
> OK, I'm marking this ready for committer attention, on the
> understanding that that doesn't include the invtrans_minmax patch.
I've started to look at this patch set. After rereading the thread,
I'm thinking that it's a mistake to just add the inverse transition
function
On 8 April 2014 21:48, Florian Pflug wrote:
> On Apr7, 2014, at 17:41 , Dean Rasheed wrote:
>> I've just finished reading through all the other patches, and they all
>> look OK to me. It's mostly straightforward stuff, so despite the size
>> it's hopefully all committable once the base patch goes
On Apr9, 2014, at 02:55 , David Rowley wrote:
> On Wed, Apr 9, 2014 at 8:48 AM, Florian Pflug wrote:
>
> As explain above, invtrans_bool is a bit problematic, since it carries
> a real risk of performance regressions. It's included for completeness'
> sake, and should probably not be committed a
On Wed, Apr 9, 2014 at 8:48 AM, Florian Pflug wrote:
>
> As explain above, invtrans_bool is a bit problematic, since it carries
> a real risk of performance regressions. It's included for completeness'
> sake, and should probably not be committed at this time.
>
>
Did you mean to write invtrans_m
On 7 April 2014 14:09, Florian Pflug wrote:
> On Apr5, 2014, at 09:55 , Dean Rasheed wrote:
>> On 5 April 2014 08:38, Dean Rasheed wrote:
>>> [snip] releasing it in this state feels a little half-baked
>>> to me.
>>>
>>
>> I regret writing that almost as soon as I sent it. The last of those
>> q
On Apr5, 2014, at 09:55 , Dean Rasheed wrote:
> On 5 April 2014 08:38, Dean Rasheed wrote:
>> [snip] releasing it in this state feels a little half-baked
>> to me.
>>
>
> I regret writing that almost as soon as I sent it. The last of those
> queries is now over 10 times faster than HEAD, which
On 5 April 2014 08:38, Dean Rasheed wrote:
> [snip] releasing it in this state feels a little half-baked
> to me.
>
I regret writing that almost as soon as I sent it. The last of those
queries is now over 10 times faster than HEAD, which is certainly
worthwhile. What bugs me is that there is so m
On 4 April 2014 11:56, Florian Pflug wrote:
>
>> On 04.04.2014, at 09:40, Dean Rasheed wrote:
>>
>> I'm not sure how much additional work is required to sort this out,
>> but to me it looks more realistic to target 9.5 than 9.4, so at this
>> point I tend to think that the patch ought to be marke
On 2014-04-04 12:56:55 +0200, Florian Pflug wrote:
>
> > On 04.04.2014, at 09:40, Dean Rasheed wrote:
> >
> > I'm not sure how much additional work is required to sort this out,
> > but to me it looks more realistic to target 9.5 than 9.4, so at this
> > point I tend to think that the patch ought
> On 04.04.2014, at 09:40, Dean Rasheed wrote:
>
> I'm not sure how much additional work is required to sort this out,
> but to me it looks more realistic to target 9.5 than 9.4, so at this
> point I tend to think that the patch ought to be marked as returned
> with feedback.
I think the patch
>> ), which seem reasonable. But
> then I started testing performance, and I found cases where the
> improvement is not nearly what I expected.
>
> The example cited at the start of this thread is indeed orders of
> magnitude faster than HEAD:
>
> SELECT SUM(n::int) OVER (ROWS BETWEEN CURRENT ROW
On 1 April 2014 20:58, Florian Pflug wrote:
> On Apr1, 2014, at 10:08 , Dean Rasheed wrote:
>> On 31 March 2014 01:58, Florian Pflug wrote:
>>> Attached are updated patches that include the EXPLAIN changes mentioned
>>> above and updated docs.
>>>
>>
>> These patches need re-basing --- they no l
On 31 March 2014 01:58, Florian Pflug wrote:
> Attached are updated patches that include the EXPLAIN changes mentioned
> above and updated docs.
>
These patches need re-basing --- they no longer apply to HEAD.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 27 March 2014 21:01, Florian Pflug wrote:
> First, sorry guys for letting this slide - I was overwhelmed by other works,
> and this kind of slipped my mind :-(
>
> On Mar27, 2014, at 09:04 , Dean Rasheed wrote:
>> On 26 March 2014 19:43, David Rowley wrote:
>>> On Thu, Mar 27, 2014 at 7:33 AM
First, sorry guys for letting this slide - I was overwhelmed by other works,
and this kind of slipped my mind :-(
On Mar27, 2014, at 09:04 , Dean Rasheed wrote:
> On 26 March 2014 19:43, David Rowley wrote:
>> On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane wrote:
>>>
>>> David Rowley writes:
On 26 March 2014 19:43, David Rowley wrote:
> On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane wrote:
>>
>> David Rowley writes:
>> > I've attached an updated invtrans_strictstrict_base patch which has the
>> > feature removed.
>>
>> What is the state of play on this patch? Is the latest version what'
On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane wrote:
> David Rowley writes:
> > I've attached an updated invtrans_strictstrict_base patch which has the
> > feature removed.
>
> What is the state of play on this patch? Is the latest version what's in
>
> http://www.postgresql.org/message-id/64f96fd9
David Rowley writes:
> I've attached an updated invtrans_strictstrict_base patch which has the
> feature removed.
What is the state of play on this patch? Is the latest version what's in
http://www.postgresql.org/message-id/64f96fd9-64d1-40b9-8861-e61820292...@phlo.org
plus this sub-patch? Is e
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday users
>>> got of making sense of it?
>
>> T
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday users
>>> got of making sense of it?
>
>> T
Florian Pflug writes:
> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>> My advice is to lose the EXPLAIN output entirely. If the authors of
>> the patch can't agree on what it means, what hope have everyday users
>> got of making sense of it?
> The question isn't what the current output means, but
On Wed, Mar 5, 2014 at 10:49 PM, Tom Lane wrote:
>
> [ shrug... ] They can see whether the Window plan node is where the time
> is going. It's not apparent to me that the extra numbers you propose to
> report will edify anybody.
Perhaps just saying "Incremental Window Function" versus "Iterated
On Mar5, 2014, at 18:27 , Dean Rasheed wrote:
> On 5 March 2014 14:35, Florian Pflug wrote:
>> When I added the EXPLAIN stuff, I initially simply reported the number
>> of times nodeWindowAgg has to restart the aggregation. The problem with
>> that approach is that not all restarts carry the same
On Mar5, 2014, at 18:37 , Tom Lane wrote:
> Dean Rasheed writes:
>> I think we really need a larger consensus on this though, so I'd be
>> interested to hear what others think.
>
> My advice is to lose the EXPLAIN output entirely. If the authors of
> the patch can't agree on what it means, what
Tom,
I did not follow the thread very close, so I need to look what the
ambiguity is there, however I would love to see window rescans in explain
analyze.
I have great experience in tuning Oracle queries.
There are features in PostgreSQL's explain analyze that I miss badly in
Oracle: 'rows remove
Dean Rasheed writes:
> I think we really need a larger consensus on this though, so I'd be
> interested to hear what others think.
My advice is to lose the EXPLAIN output entirely. If the authors of
the patch can't agree on what it means, what hope have everyday users
got of making sense of it?
On 5 March 2014 14:35, Florian Pflug wrote:
> On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
>> On 3 March 2014 23:00, Florian Pflug wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate->aggfwdtrans /
(inst->n
On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
> On 3 March 2014 23:00, Florian Pflug wrote:
>>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>>
>>> double tperrow = winaggstate->aggfwdtrans /
>>> (inst->nloops * inst->ntuples);
>>>
>>> If the node is exe
On 3 March 2014 23:00, Florian Pflug wrote:
>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>
>>double tperrow = winaggstate->aggfwdtrans /
>>(inst->nloops * inst->ntuples);
>>
>> If the node is executed multiple times, aggfwdtrans will be reset in
>> e
On 25 February 2014 12:33, Florian Pflug wrote:
> On Feb24, 2014, at 17:50 , Dean Rasheed wrote:
>> On 20 February 2014 01:48, Florian Pflug wrote:
>>> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
In fact, I'm
currently leaning towards just forbidding non-strict forward transition
On Feb24, 2014, at 17:50 , Dean Rasheed wrote:
> On 20 February 2014 01:48, Florian Pflug wrote:
>> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
>>> In fact, I'm
>>> currently leaning towards just forbidding non-strict forward transition
>>> function with strict inverses, and adding non-NULL
On 20 February 2014 01:48, Florian Pflug wrote:
> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
>> In fact, I'm
>> currently leaning towards just forbidding non-strict forward transition
>> function with strict inverses, and adding non-NULL counters to the
>> aggregates that then require them.
On Jan29, 2014, at 09:59 , Dean Rasheed wrote:
> On 28 January 2014 20:16, Florian Pflug wrote:
>> On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
>>> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
>>> executor. To me, that seems overly restrictive --- if transfn is
>>> st
On 28 January 2014 20:16, Florian Pflug wrote:
> On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
>> strict transfn vs non-strict inv_transfn
>>
>>
>> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
>> executor. To me, that seems overl
On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
> strict transfn vs non-strict inv_transfn
>
>
> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
> executor. To me, that seems overly restrictive --- if transfn is
> strict, then you kno
On 25 January 2014 02:21, Florian Pflug wrote:
> I've now split this up into
>
> invtrans_base: Basic machinery plus tests with SQL-language aggregates
> invtrans_arith: COUNT(),SUM(),AVG(),STDDEV() and the like
> invtrans_minmax: MIN(),MAX(),BOOL_AND(),BOOL_OR()
> invtrans_collecting: ARRAY_AGG()
On Jan26, 2014, at 00:24 , David Rowley wrote:
>> On Sat, Jan 25, 2014 at 3:21 PM, Florian Pflug wrote:
>> On Jan24, 2014, at 08:47 , Dean Rasheed wrote:
>> The invtrans_minmax patch doesn't contain any patches yet - David, could
>> you provide some for these functions, and also for bool_and and
On Sat, Jan 25, 2014 at 3:21 PM, Florian Pflug wrote:
> On Jan24, 2014, at 08:47 , Dean Rasheed wrote:
> The invtrans_minmax patch doesn't contain any patches yet - David, could
> you provide some for these functions, and also for bool_and and bool_or?
> We don't need to test every datatype, but
On Jan25, 2014, at 09:50 , David Rowley wrote:
> On Thu, Jan 23, 2014 at 1:57 PM, Florian Pflug wrote:
>> On Jan23, 2014, at 01:17 , David Rowley wrote:
>> > On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
>> >> If you want to play with
>> >> this, I think the first step has to be to fin
David Rowley writes:
> My point was more that since sum(float) can give different results if it
> used an index scan rather than a seq scan, trying to get the inverse
> transition to match something that gives varying results sounds like a
> tricky task to take on.
This is just a variant of the s
On Thu, Jan 23, 2014 at 1:57 PM, Florian Pflug wrote:
> On Jan23, 2014, at 01:17 , David Rowley wrote:
> > On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
> >> If you want to play with
> >> this, I think the first step has to be to find a set of guarantees that
> >> SUM(float) is suppose
On Jan24, 2014, at 08:47 , Dean Rasheed wrote:
> I think it should probably be broken up. It might be overly ambitious
> to try to get all of this committed during this commitfest, and in any
> case, I suspect that the committer would probably choose to commit it
> in stages. Perhaps something lik
On 22 January 2014 09:54, David Rowley wrote:
> I've performed some more benchmarks on this patch tonight. The results and
> full recreation scripts are attached along with the patch it was tested
> against.
>
I noticed that the rate of changes to this patch has dropped off,
which I took as sign
On Jan23, 2014, at 01:07 , David Rowley wrote:
> On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug wrote:
>> On Jan20, 2014, at 08:42 , David Rowley wrote:
>> >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>> >> * I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive change,
>
On Jan23, 2014, at 01:17 , David Rowley wrote:
> On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
>> If you want to play with
>> this, I think the first step has to be to find a set of guarantees that
>> SUM(float) is supposed to meet. Currently, SUM(float) guarantees that if the
>> summand
On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
> On Jan21, 2014, at 10:53 , David Rowley wrote:
> > It came to me that it might be possible to implement inverse transitions
> > for floating point aggregates by just detecting if precision has been
> > lost during forward transitions.
> >
On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug wrote:
> On Jan20, 2014, at 08:42 , David Rowley wrote:
> >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
> >> * I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive
> change, and
> >> it's the last commit, so if you object to
On Jan20, 2014, at 15:20 , Florian Pflug wrote:
> * In CREATE AGGREGATE, we should state the precise axioms we assume about
> forward
> and inverse transition functions. The last time I read the text there, it was
> a bit ambiguous about whether inverse transition functions assume
> commutativit
On Jan21, 2014, at 10:53 , David Rowley wrote:
> It came to me that it might be possible to implement inverse transitions
> for floating point aggregates by just detecting if precision has been
> lost during forward transitions.
>
> I've written the test to do this as:
>
> IF state.value + value
On Sun, Dec 15, 2013 at 2:00 PM, Tom Lane wrote:
> Greg Stark writes:
> > On 14 Dec 2013 15:40, "Tom Lane" wrote:
> >> I think you *can't* cover them for the float types; roundoff error
> >> would mean you don't get the same answers as before.
>
> > I was going to say the same thing. But then I
On Jan20, 2014, at 08:42 , David Rowley wrote:
>> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>> * An assert that the frame end doesn't move backwards - I realized that
>> it is after all easy to do that, if it's done after the loop which adds
>> the new values, not before.
>
> I'v
On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
> On Jan19, 2014, at 20:00 , David Rowley wrote:
> > I've applied that patch again and put in the sort operators.
>
> I've push a new version to https://github.com/fgp/postgres/tree/invtrans
> which includes
>
> * A bunch of missing declarati
On Jan19, 2014, at 20:00 , David Rowley wrote:
> I've applied that patch again and put in the sort operators.
I've push a new version to https://github.com/fgp/postgres/tree/invtrans
which includes
* A bunch of missing declaration for *_inv functions
* An assert that the frame end doesn't move
On Mon, Jan 20, 2014 at 8:42 PM, David Rowley wrote:
> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>
>> * EXPLAIN VERBOSE ANALYZE now shows the max. number of forward aggregate
>> transitions per row and aggregate. It's a bit imprecise, because it
>> doesn't
>> track the count per
On Jan19, 2014, at 20:00 , David Rowley wrote:
> I've applied that patch again and put in the sort operators.
I've push a new version to https://github.com/fgp/postgres/tree/invtrans
This branch includes the following changes
* A bunch of missing declaration for *_inv functions
* An assert that
On Mon, Jan 20, 2014 at 5:53 AM, Florian Pflug wrote:
> On Jan19, 2014, at 05:27 , David Rowley wrote:
> >> I just finished implementing the inverse transition functions for
> bool_and
> >> and bool_or, these aggregates had a sort operator which I assume would
> have
> >> allowed an index scan t
On Jan19, 2014, at 05:27 , David Rowley wrote:
>> I just finished implementing the inverse transition functions for bool_and
>> and bool_or, these aggregates had a sort operator which I assume would have
>> allowed an index scan to be performed, but since I had to change the first
>> argument of t
On Sat, Jan 18, 2014 at 11:34 AM, David Rowley wrote:
>
> The latest version of the patch is attached.
>
>
I've attached an updated version of the patch.
I'm now using github to track the changes on the patch, so I've included
the commit sha in the file name of the latest commit that this patch
On Sun, Jan 19, 2014 at 5:27 PM, David Rowley wrote:
>
>> >> It's probably far more worth it for the bool and/or aggregates. We
>> could just
>> >> keep track of the values aggregated and the count of values as "true"
>> and return
>> >> true if those are the same in the case of "AND", then check
On Sun, Jan 19, 2014 at 3:22 AM, Florian Pflug wrote:
>
> BTW, this made me realize that MIN and MAX currently have the same issue -
> they'll rescan if the inputs are all equal. We could avoid that by doing
> what
> you did with dscale - track the number of times we've seen the maximum. I
> wond
On Jan18, 2014, at 06:15 , David Rowley wrote:
>> On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote:
>> On Jan17, 2014, at 23:34 , David Rowley wrote:
>>> The test turned out to become:
>>> if (state->expectedScale == -1)
>>> state->expectedScale = X.dscale;
>>> else if
On Sat, Jan 18, 2014 at 6:15 PM, David Rowley wrote:
> On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote:
>
>> * Don't we need to check for volatile function in the filter expression
>> too?
>>
>
>>
> I did manual testing on this before and the volatility test for the
> aggregate arguments se
On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote:
> First, I've go the feeling that I should somehow update the commitfest app,
> but I don't really know in which way. Should I put myself in as a reviewer,
> or as a second author? Or neither? Suggestions welcome...
>
>
We I guess you're both
First, I've go the feeling that I should somehow update the commitfest app,
but I don't really know in which way. Should I put myself in as a reviewer,
or as a second author? Or neither? Suggestions welcome...
On Jan17, 2014, at 23:34 , David Rowley wrote:
> The test turned out to become:
>
David Rowley writes:
> I just thought that my idea was good enough and very cheap too, won't all
> numerics that are actually stored in a column have the same scale anyway?
No; unconstrained numeric columns (ie, if you just say "numeric") don't
force their contents to any particular scale. It mi
On Sat, Jan 18, 2014 at 10:42 AM, David Rowley wrote:
>
>> You could do better than that - the numeric problem amounts to tracking
>> the maximum
>> scale AFAICS, so it'd be sufficient to restart if we remove a value whose
>> scale equals
>> the current maximum. But if we do SUM(numeric) at all,
1 - 100 of 204 matches
Mail list logo
