Thanks!
On Mon, Jun 16, 2014 at 3:58 PM, Tom Lane wrote:
> I wrote:
>> Gurjeet Singh writes:
>>> I tried to eliminate the 'pending' list, but I don't see a way around it.
>>> We need temporary storage somewhere to store the branches encountered on
>>> the right; in recursion case the call stack
I wrote:
> Gurjeet Singh writes:
>> I tried to eliminate the 'pending' list, but I don't see a way around it.
>> We need temporary storage somewhere to store the branches encountered on
>> the right; in recursion case the call stack was serving that purpose.
> I still think we should fix this in
Gurjeet Singh writes:
> I tried to eliminate the 'pending' list, but I don't see a way around it.
> We need temporary storage somewhere to store the branches encountered on
> the right; in recursion case the call stack was serving that purpose.
I still think we should fix this in the grammar, rat
On Thu, Jul 18, 2013 at 1:54 PM, Gurjeet Singh wrote:
> On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane wrote:
>
>>
>> > Because simpler code is less likely to have bugs and is easier to
>> > maintain.
>>
>> I agree with that point, but one should also remember Polya's Inventor's
>> Paradox: the more
On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane wrote:
>
> > Because simpler code is less likely to have bugs and is easier to
> > maintain.
>
> I agree with that point, but one should also remember Polya's Inventor's
> Paradox: the more general problem may be easier to solve. That is, if
> done righ
Robert Haas writes:
> On Wed, Jul 17, 2013 at 2:03 PM, Gurjeet Singh wrote:
>> Agreed that bushy/right-deep trees are a remote corner case, but we are
>> addressing a remote corner case in the first place (insanely long AND lists)
>> and why not handle another remote corner case right now if it d
On Wed, Jul 17, 2013 at 2:03 PM, Gurjeet Singh wrote:
> In v6 of the patch, I have deferred the 'pending' list initialization to
> until we actually hit a candidate right-branch. So in the common case the
> pending list will never be populated, and if we find a bushy or right-deep
> tree (for som
On Wed, Jul 17, 2013 at 1:25 PM, Robert Haas wrote:
> On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh wrote:
> > Agreed that there's overhead in allocating list items, but is it more
> > overhead than pushing functions on the call stack? Not sure, so I leave
> it
> > to others who understand suc
On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh wrote:
> Agreed that there's overhead in allocating list items, but is it more
> overhead than pushing functions on the call stack? Not sure, so I leave it
> to others who understand such things better than I do.
If you think that a palloc can ever
On 07/17/2013 05:21 AM, Gurjeet Singh wrote:
> On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule wrote:
>
>> I did a some performance tests of v5 and v6 version and there v5 is
>> little bit faster than v6, and v6 has significantly higher stddev
>>
>
> Thanks Pavel.
>
> The difference in average se
On Wed, Jul 17, 2013 at 8:21 AM, Gurjeet Singh wrote:
>
> What's the procedure of moving a patch to the next commitfest?
>
Never mind, I see an email from Josh B. regarding this on my corporate
account.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule wrote:
> I did a some performance tests of v5 and v6 version and there v5 is
> little bit faster than v6, and v6 has significantly higher stddev
>
Thanks Pavel.
The difference in average seems negligible, but stddev is interesting
because v6 does le
Hello
2013/7/15 Gurjeet Singh :
> On Sun, Jul 14, 2013 at 8:27 PM, Robert Haas wrote:
>>
>> On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus wrote:
>> >> I think it's a waste of code to try to handle bushy trees. A list is
>> >> not a particularly efficient representation of the pending list; this
On Sun, Jul 14, 2013 at 8:27 PM, Robert Haas wrote:
> On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus wrote:
> >> I think it's a waste of code to try to handle bushy trees. A list is
> >> not a particularly efficient representation of the pending list; this
> >> will probably be slower than recusi
On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus wrote:
>> I think it's a waste of code to try to handle bushy trees. A list is
>> not a particularly efficient representation of the pending list; this
>> will probably be slower than recusing in the common case. I'd suggest
>> keeping the logic to ha
> I think it's a waste of code to try to handle bushy trees. A list is
> not a particularly efficient representation of the pending list; this
> will probably be slower than recusing in the common case. I'd suggest
> keeping the logic to handle left-deep trees, which I find rather
> elegant, but
On Sun, Jun 30, 2013 at 1:08 PM, Pavel Stehule wrote:
> 2013/6/30 Gurjeet Singh :
>> On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule
>> wrote:
>>>
>>> 2013/6/30 Gurjeet Singh :
>>> > On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule
>>> >
>>> > wrote:
>>> >
>>> > How about naming those 3 variables
2013/6/30 Gurjeet Singh :
> On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule
> wrote:
>>
>> 2013/6/30 Gurjeet Singh :
>> > On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule
>> >
>> > wrote:
>> >
>> > How about naming those 3 variables as follows:
>> >
>> > root_expr_kind
>> > root_expr_name
>> > roo
On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule wrote:
> 2013/6/30 Gurjeet Singh :
> > On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule >
> > wrote:
> >
> > How about naming those 3 variables as follows:
> >
> > root_expr_kind
> > root_expr_name
> > root_bool_expr_type
>
> +1
Thanks. Attached is
2013/6/30 Gurjeet Singh :
> On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule
> wrote:
>>
>> Hello
>>
>> just one small notices
>>
>> I dislike a name "root_bool_expr", because, there is not a expression,
>> but expression type. Can you use "root_bool_expr_type" instead? It is
>> little bit longer,
On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule wrote:
> Hello
>
> just one small notices
>
> I dislike a name "root_bool_expr", because, there is not a expression,
> but expression type. Can you use "root_bool_expr_type" instead? It is
> little bit longer, but more correct. Same not best name is
Hello
just one small notices
I dislike a name "root_bool_expr", because, there is not a expression,
but expression type. Can you use "root_bool_expr_type" instead? It is
little bit longer, but more correct. Same not best name is
"root_char", maybe "root_bool_op_name"
or root_expr_type and root_o
On Tue, Jun 18, 2013 at 3:01 PM, Pavel Stehule wrote:
>
> related to
>
> https://commitfest.postgresql.org/action/patch_view?id=1130
>
> http://www.postgresql.org/message-id/cabwtf4v9rsjibwe+87pk83mmm7acdrg7sz08rq-4qyme8jv...@mail.gmail.com
>
>
> * motivation: remove recursive procession of AND/OR
Thanks for the review Pavel.
On Tue, Jun 18, 2013 at 3:01 PM, Pavel Stehule wrote:
> Hello
>
> related to
>
> https://commitfest.postgresql.org/action/patch_view?id=1130
>
> http://www.postgresql.org/message-id/cabwtf4v9rsjibwe+87pk83mmm7acdrg7sz08rq-4qyme8jv...@mail.gmail.com
>
>
> * motivation:
24 matches
Mail list logo
