Thanks!
On Mon, Jun 16, 2014 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Gurjeet Singh gurj...@singh.im 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
I wrote:
Gurjeet Singh gurj...@singh.im 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
On Thu, Jul 18, 2013 at 1:54 PM, Gurjeet Singh gurj...@singh.im wrote:
On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us 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
Gurjeet Singh gurj...@singh.im 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
On Wed, Jul 17, 2013 at 2:03 PM, Gurjeet Singh gurj...@singh.im 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 17, 2013 at 2:03 PM, Gurjeet Singh gurj...@singh.im 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
On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
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
On Wed, Jul 17, 2013 at 8:21 AM, Gurjeet Singh gurj...@singh.im 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 07/17/2013 05:21 AM, Gurjeet Singh wrote:
On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
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
On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh gurj...@singh.im 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
On Wed, Jul 17, 2013 at 1:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh gurj...@singh.im 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
Hello
2013/7/15 Gurjeet Singh gurj...@singh.im:
On Sun, Jul 14, 2013 at 8:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus j...@agliodbs.com wrote:
I think it's a waste of code to try to handle bushy trees. A list is
not a particularly efficient
On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus j...@agliodbs.com 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
On Sun, Jul 14, 2013 at 8:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus j...@agliodbs.com 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
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 pavel.steh...@gmail.com wrote:
2013/6/30 Gurjeet Singh gurj...@singh.im:
On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/6/30 Gurjeet Singh gurj...@singh.im:
On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule
On Tue, Jun 18, 2013 at 3:01 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
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
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_op_name
On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
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
2013/6/30 Gurjeet Singh gurj...@singh.im:
On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule pavel.steh...@gmail.com
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
On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
2013/6/30 Gurjeet Singh gurj...@singh.im:
On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
How about naming those 3 variables as follows:
root_expr_kind
root_expr_name
2013/6/30 Gurjeet Singh gurj...@singh.im:
On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/6/30 Gurjeet Singh gurj...@singh.im:
On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule
pavel.steh...@gmail.com
wrote:
How about naming those 3 variables as
Thanks for the review Pavel.
On Tue, Jun 18, 2013 at 3:01 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
related to
https://commitfest.postgresql.org/action/patch_view?id=1130
http://www.postgresql.org/message-id/cabwtf4v9rsjibwe+87pk83mmm7acdrg7sz08rq-4qyme8jv...@mail.gmail.com
24 matches
Mail list logo
