On Sat, Oct 28, 2017 at 3:07 PM, Robert Haas wrote:
> On Fri, Oct 27, 2017 at 1:01 PM, Jeevan Chalke
> wrote:
> > 1. Added separate patch for costing Append node as discussed up-front in
> the
> > patch-set.
> > 2. Since we now cost Append node, we don't need
&g
ation
patch.
3. Updated rows in test-cases so that we will get partition-wise plans.
Thanks
On Wed, Oct 18, 2017 at 9:53 AM, Dilip Kumar wrote:
> On Tue, Oct 17, 2017 at 10:44 PM, Jeevan Chalke
> wrote:
> >
>
> > I didn't get what you mean by regression here. Can yo
On Tue, Oct 17, 2017 at 7:13 PM, Dilip Kumar wrote:
> On Fri, Oct 13, 2017 at 12:06 PM, Jeevan Chalke
> wrote:
> >
> While playing around with the patch I have noticed one regression with
> the partial partition-wise aggregate.
>
> I am consistently able to reproduce
;
Agree, but those magic numbers used only once at that place. But here there
are two places. So if someone wants to update it, (s)he needs to make sure
to update that at two places. To minimize that risk, having a #define seems
better.
>
> --
> David Rowley http://www.2nd
16925.01) / 100);
1.8
-- With 1 rows (so no Gather too)
# select current_Setting('cpu_tuple_cost')::float8 / ((170.01 * (1.919 /
1.424) - 170.01) / 1);
1.7
So it is not so straight forward to come up the correct heuristic here.
Thus using 50% of cpu_tuple_cost look good
On Tue, Oct 10, 2017 at 10:27 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Tue, Oct 10, 2017 at 3:15 AM, David Rowley
> wrote:
> > On 10 October 2017 at 01:10, Jeevan Chalke
> > wrote:
> >> Attached new patch set having HEAD at 84ad4
end paths and then adds
> finalization
> path if necessary. The code to add finalization path seems to be similar
> to the
> code that adds finalization path for parallel query. May be we could take
> out
> common code into a function and call that function in two places. I see
be worthwhile to fix
> the reason why we would require this GUC. If the regular aggregation
> has cost lesser than partition-wise aggregation in most of the cases,
> then probably we need to fix the cost model.
>
Yep. I will have a look mean-while.
>
> I will continue reviewin
se, but testcase is working as expected.
However running those steps on psql reproduces the crash (not consistent
though).
Looking into it. Thanks for reporting.
> Thanks & Regards,
> Rajkumar Raghuwanshi
> QMG, EnterpriseDB Corporation
>
--
Jeevan Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
able use of partition-wise strategy, one for each of join,
> aggregation and sorting. Having granular switches would be useful for
> debugging and may be to turn partition-wise strategies off when they
> are not optimal.
I think having a granular control over each of these optimization w
On Tue, Sep 12, 2017 at 6:21 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Tue, Sep 12, 2017 at 3:24 PM, Rajkumar Raghuwanshi <
> rajkumar.raghuwan...@enterprisedb.com> wrote:
>
>>
>> Hi Jeevan,
>>
>> I have started testi
On Tue, Sep 12, 2017 at 8:12 PM, Robert Haas wrote:
> On Tue, Sep 12, 2017 at 7:08 AM, Jeevan Chalke
> wrote:
> > This patch clearly improves the planning time with given conditions.
> >
> > To verify that, I have created a table like:
> > create table foo(a int,
On Tue, Sep 12, 2017 at 3:24 PM, Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
>
> On Fri, Sep 8, 2017 at 5:47 PM, Jeevan Chalke com> wrote:
>
>> Here are the new patch-set re-based on HEAD (f0a0c17) and
>> latest partition-wise join (v29) pa
cessarily cascade.
>
> For partitioning, it may be that we've got enough restrictions in
> place on what can happen that we can assume everything can cascade.
> Actually, I hope that's true, since the partitioned table has no
> storage of its own.
>
> --
> Robert
Hi Pavel,
On Sat, Sep 9, 2017 at 11:42 AM, Pavel Stehule
wrote:
> Hi
>
> 2017-09-08 9:36 GMT+02:00 Jeevan Chalke :
>
>> Hi Pavel,
>> I like the idea of using parameter name instead of $n symbols.
>>
>> However, I am slightly worried that, at execution time
On Wed, Aug 23, 2017 at 4:43 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hi,
>
> Attached is the patch to implement partition-wise aggregation/grouping.
>
> As explained earlier, we produce a full aggregation for each partition when
> partition keys are
argvariable = plpgsql_build_variable((argnames &&
argnames[i][0] != '\0') ?
+argnames[i] : buf,
+0, argdtype, false);
This requires no new variable and thus no more changes el
& Schönig GmbH
> Gröhrmühlgasse 26
> A-2700 Wiener Neustadt
> Web: http://www.postgresql-support.de, http://www.cybertec.at
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Jeevan Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
to the open commitfest.
>
> Thanks. Added. https://commitfest.postgresql.org/14/1195/
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make
...@mail.gmail.com
On Tue, Mar 21, 2017 at 12:47 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hi all,
>
> Declarative partitioning is supported in PostgreSQL 10 and work is already
> in
> progress to support partition-wise joins. Here is a proposal for
> partition-wis
rogress
in terminal 1.
SELECT pg_terminate_backend();
I thought it worth posting here to get others attention.
I have observed this on the master branch, but can also be reproducible on
back-branches.
Thanks
--
Jeevan Chalke
Principal Software Engineer, Product Development
EnterpriseDB Cor
nd any other changes required
to be applied first?
How the plan look like when GROUP BY key does not match with the
partitioning key i.e. GROUP BY b.v ?
>
> [1] https://www.postgresql.org/message-id/9666.1491295317%40localhost
>
> [2] https://commitfest.postgresql.org/14/994/
>
>
On Tue, Mar 21, 2017 at 1:47 PM, Antonin Houska wrote:
> Jeevan Chalke wrote:
>
> > Declarative partitioning is supported in PostgreSQL 10 and work is
> already in
> > progress to support partition-wise joins. Here is a proposal for
> partition-wise
> > agg
join
feature.
[1]
https://www.postgresql.org/message-id/CAFjFpRcbY2QN3cfeMTzVEoyF5Lfku-ijyNR%3DPbXj1e%3D9a%3DqMoQ%40mail.gmail.com
Thanks
--
Jeevan Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
pg_partwise_agg_WIP.patch
OIN is pushed down to
remote server, thus need to update this comment.
Rest of the changes look good to me.
Thanks
--
Jeevan Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
or
aggregate functions.
3.
Typo:
don's => don't
Rest of the changes look good to me.
Thanks
> Thanks,
>
> PG-Strom Project / NEC OSS Promotion Center
> KaiGai Kohei
>
>
> > -Original Message-
> > From: Robert Haas [mailto:robertmh.
I think
this is not possible here since 0 can be a legal user provided value which
cannot be set as a default (default is all rows).
However do you think, can we avoid that? Is there any other way so that we
don't need every node having ps_numTuples to be set explicitly?
Apart from this p
On Wed, Nov 2, 2016 at 10:09 PM, Tom Lane wrote:
> In 9.6, "make installcheck" in contrib/postgres_fdw takes a shade
> under 3 seconds on my machine. In HEAD, it's taking 10 seconds.
> I am not happy, especially not since there's no parallelization
> of the contrib regression tests. That's a di
On Sat, Oct 22, 2016 at 9:09 PM, Tom Lane wrote:
> brolga is still not terribly happy with this patch: it's choosing not to
> push down the aggregates in one of the queries. While I failed to
> duplicate that result locally, investigation suggests that brolga's result
> is perfectly sane; in fac
On Thu, Oct 20, 2016 at 12:49 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> The patch compiles and make check-world doesn't show any failures.
>
> >>
> >
> >
> > I have tried it. Attached separate patch for it.
> > However I have noticed that istoplevel is always false (at-least f
On Thu, Sep 8, 2016 at 10:41 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> I think we should try to measure performance gain because of aggregate
> pushdown. The EXPLAIN
> doesn't show actual improvement in the execution times.
>
I did performance testing for aggregate push d
On Mon, Sep 26, 2016 at 6:15 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> This patch will need some changes to conversion_error_callback(). That
> function reports an error in case there was an error converting the
> result obtained from the foreign server into an internal datum
Hi Stephen,
> 4. It will be good if we have an example for this in section
> > "5.7. Row Security Policies"
>
> I haven't added one yet, but will plan to do so.
>
> I think you are going to add this in this patch itself, right?
I have reviewed your latest patch and it fixes almost all my review
On Tue, Sep 27, 2016 at 12:45 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hello Stephen,
>
> I am reviewing the latest patch in detail now and will post my review
> comments later.
>
Here are the review comments:
1. In documentation, we should put both
Hello Stephen,
On Tue, Sep 27, 2016 at 12:57 AM, Stephen Frost wrote:
> Jeevan,
>
> * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote:
> > I have started reviewing this patch and here are couple of points I have
> > observed so far:
> >
> > 1. Patch a
Hi,
I have started reviewing this patch and here are couple of points I have
observed so far:
1. Patch applies cleanly
2. make / make install / initdb all good.
3. make check (regression) FAILED. (Attached diff file for reference).
Please have a look over failures.
Meanwhile I will go ahead and
On Mon, Sep 12, 2016 at 7:27 AM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote:
> > > Stephen Frost writes:
> > >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > >>> Can't you keep those words as Sconst
On Mon, Sep 12, 2016 at 5:19 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Mon, Sep 12, 2016 at 12:20 PM, Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> While testing "Aggregate pushdown", i found
On Mon, Sep 12, 2016 at 12:20 PM, Prabhat Sahu <
prabhat.s...@enterprisedb.com> wrote:
> Hi,
>
> While testing "Aggregate pushdown", i found the below error:
> -- GROUP BY alias showing different behavior after adding patch.
>
> -- Create table "t1", insert few records.
> create table t1(c1 int);
On Thu, Sep 8, 2016 at 10:41 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
>
>
>> While checking for shippability, we build the target list which is passed
>> to
>> the foreign server as fdw_scan_tlist. The target list contains
>> a. All the GROUP BY expressions
>> b. Shippable
Hi,
Changes look good to me.
However there are couple of minor issues need to be fixed.
1.
"under" repeated on second line. Please remove.
+if and when CustomScanState is located under
+under LimitState; which implies the underlying node is
not
2.
Typo: dicsussion => discussion
Please f
Hi,
On Mon, Aug 29, 2016 at 7:25 AM, Kouhei Kaigai wrote:
> Hello,
>
> The attached patch adds an optional callback to support special
> optimization
> if ForeignScan/CustomScan are located under the Limit node in plan-tree.
>
> Our sort node wisely switches the behavior when we can preliminary
Hi Aleksander,
This has already been fixed with commit
4f9f495889d3d410195c9891b58228727b340189
Thanks
On Fri, Apr 8, 2016 at 6:02 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> Hello
>
> Currently there is a following piece of code in snapmgr.c:
>
> ```
> /* Copy all required fi
On Tue, Aug 30, 2016 at 6:51 PM, Pavel Stehule
wrote:
> Hi
>
> 2016-08-30 15:02 GMT+02:00 Jeevan Chalke :
>
>> Hi all,
>>
>> Attached is the patch which adds support to push down aggregation and
>> grouping
>> to the foreign server for postgres_fdw. P
Hi,
While playing with LATERAL along with some aggregates in sub-query, I have
observed somewhat unusual behavior.
Consider following steps:
create table tab1(c1 int, c2 int);
insert into tab1 select id, 1 from generate_series(1, 3) id;
create function sum_tab1(extra int) returns setof bigint as
Hi,
I have reviewed the patch and it looks good to me.
make/make install/make check is fine (when done without -Wall -Werror).
Here are few comments:
1.
With -Wall -Werror, I see couple of warnings:
postgres_fdw.c: In function ‘estimate_path_cost_size’:
postgres_fdw.c:2248:13: error: ‘run_cost’
On Fri, Oct 16, 2015 at 3:10 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Thu, Oct 15, 2015 at 10:44 PM, Robert Haas
> wrote:
>
>> On Thu, Oct 15, 2015 at 3:04 AM, Kyotaro HORIGUCHI
>> wrote:
>> > I confirmed that an
On Thu, Oct 15, 2015 at 10:44 PM, Robert Haas wrote:
> On Thu, Oct 15, 2015 at 3:04 AM, Kyotaro HORIGUCHI
> wrote:
> > I confirmed that an epqtuple of foreign parameterized scan is
> > correctly rejected by fdw_recheck_quals with modified outer
> > tuple.
> >
> > I have no objection to this and
> On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
>
>>
>> In the interest of full disclosure, I asked Ashutosh to work on this
>> patch and have discussed the design with him several times. I believe
>> that this is a good direction for PostgreSQL to be going. It's
>> trivially easy right now
On Fri, Oct 9, 2015 at 3:35 PM, Etsuro Fujita
wrote:
Hi,
Just to have hands on, I started looking into this issue and trying to
grasp it as this is totally new code for me. And later I want to review
this code changes.
I have noticed that, this thread started saying we are getting a crash
with
On Thu, Sep 24, 2015 at 10:22 PM, Tom Lane wrote:
> Jeevan Chalke writes:
> > On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote:
> >> After a bit more thinking and experimentation, I propose the attached
> >> patch.
>
> > I had a look over the patch and revi
On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote:
> I wrote:
> > Hm ... actually, we probably need *both* types of changes if that's
> > what we believe the state values mean.
>
>
I too was confused with the state explanations from the code-comments which
we have them now. With your explanation h
On Wed, Sep 23, 2015 at 7:29 PM, Tom Lane wrote:
> Removing that entirely would be quite incorrect, because then you'd be
> lying to the parent node about what collation your node outputs.
>
Yes. I too thought so and thus wanted to fix that code block by
considering the default collation.
>
>
Hi Tom,
On Tue, Sep 22, 2015 at 12:31 AM, Tom Lane wrote:
>
> I think you're blaming the wrong code; RelabelType is handled basically
> the same as most other cases.
>
> It strikes me that this function is really going about things the wrong
> way. Rather than trying to determine the output col
Hi,
It is observed that, when we have one remote (huge) table and one local
(small) table and a join between them, then
1. If the column type is text, then we push the join qual to the remote
server, so that we will have less rows to fetch, and thus execution time
is very less.
2. If the
Hi,
This will fail too.
Note that, when we have only one element in GROUPING SETS,
we add that in group by list and set parse->groupingSets to NULL.
And hence it will have same issue.
However tests added in my patch failing too.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product D
Hi
It looks like we have broken the ROW expression without explicit
ROW keyword in GROUP BY.
I mean, after Grouping sets merge, if we have (c1, c2) in group by,
we are treating it as ROW expression for grouping, but at the same
time we are allowing individual column in the target list.
However thi
On Sat, Jul 18, 2015 at 12:27 AM, Andrew Gierth wrote:
> > "Kyotaro" == Kyotaro HORIGUCHI
> writes:
>
> Kyotaro> Hello, this looks to be a kind of thinko. The attached patch
> Kyotaro> fixes it.
>
> No, that's still wrong. Just knowing that there is a List is not enough
> to tell whether t
Hi,
When we have text column in the GROUPING SETS (and with some specific
order of columns), we are getting error saying
"could not determine which collation to use for string comparison"
Here is the example:
postgres=# select sum(ten) from onek group by rollup(four::text), two
order by 1;
ERROR
On Wed, Jul 15, 2015 at 10:21 PM, Andrew Gierth wrote:
> >>>>> "Jeevan" == Jeevan Chalke writes:
>
> Jeevan> Hi,
> Jeevan> It looks like we do support nested GROUPING SETS, I mean Sets
> Jeevan> withing Sets, not other types. However this n
Hi,
It looks like we do support nested GROUPING SETS, I mean Sets withing
Sets, not other types. However this nesting is broken.
Here is the simple example where I would expect three rows in the
result. But unfortunately it is giving "unrecognized node type"
error. Which is something weird and
On Tue, Jul 14, 2015 at 4:23 PM, Andrew Gierth
wrote:
> >>>>> "Jeevan" == Jeevan Chalke writes:
>
> Jeevan> Basically, when we have only one element in GROUING SETS, we
> Jeevan> are assuming it as a simple GROUP BY with one column. Due to
>
Hi,
I have observed some fishy behavior related to GROUPING in HAVING clause
and when we have only one element in GROUPING SETS.
Basically, when we have only one element in GROUING SETS, we are assuming
it as a simple GROUP BY with one column. Due to which we are ending up with
this error.
If we
On Fri, Jul 3, 2015 at 2:12 AM, Tom Lane wrote:
> Jeevan Chalke writes:
> > Attached patch which fixes my review comments.
>
> Applied with minor adjustments (mostly cosmetic, but did neither of you
> notice the compiler warning?)
>
Oops. Sorry for that.
Added
Hi,
I have observed that we are not tab-completing word PASSWORD in the
following
syntaxes:
1.
CREATE|ALTER ROLE|USER rolname
2.
CREATE|ALTER ROLE|USER rolname WITH
PASSWORD is used many times and should be in the tab-complete list.
Was there any reason we have deliberately kept this out?
If y
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Patch looks good to pass to committer.
The new status of thi
Hi
Patch looks excellent now. No issues.
Found a typo which I have fixed in the attached patch.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/p
On Mon, Jun 8, 2015 at 8:19 PM, Andres Freund wrote:
> On 2015-06-08 14:44:53 +0000, Jeevan Chalke wrote:
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements feature: tested, pass
Hi,
I found some dead code in CREATE/RENAME ROLE code path.
Attached patch to remove those.
We have introduced RoleSpec and handled public and none role names in
grammar
itself. We do have these handling in CreateRole() and RenameRole() which is
NO more valid now.
Here is the related commit:
com
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
This is trivial bug fix in the area of hiding error context.
Hi,
Attached patch which fixes my review comments.
Since code changes were good, just fixed reported cosmetic changes.
David, can you please cross check?
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff -
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I have reviewed the patch.
Here are my review comments:
1. P
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, failed
I have reviewed this patch. Most of the code is just rearrang
Pavel, will it be good if you separately submit the
"bugfix: incomplete implementation of errhidecontext"
patch in this commitfest?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I agree with Peter that "We don't tab-complete everything we possibly
Hi,
If function is created with the LEAKPROOF option, then pg_get_functiondef()
does not show that in the returned definition.
Is it expected OR are we missing that option in pg_get_functiondef().
However only superuser can define a leakproof function.
Was this the reson we are not showing that i
Hi Andres,
Following commit (related to this discussion),
added a bug when we use BKI_FORCE_NULL.
commit eb68379c38202180bc8e33fb9987284e314b7fc8
Author: Andres Freund
Date: Sat Feb 21 22:25:49 2015 +0100
Allow forcing nullness of columns during bootstrap.
Bootstrap determines whethe
Álvaro,
I think, there are few open questions here and thus marking it back to "Waiting
on Author".
Please have your views on the review comments already posted.
Also make changes as Tom suggested about placing pstate at the beginning.
I am more concerned about this:
1.
postgres=# create or re
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good. Passing it to committer.
The new status of this
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
> 1.
> +#include "utils/acl.h"
>
> Can you pl
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Tom suggested few changes already which I too think author needs to addre
> The attatched are the fourth version of this patch.
>
> 0001-Add-regrole_v4.patch
> 0002-Add-regnamespace_v4.patch
>
Seems like you have missed to attach both the patches.
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Com
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I have reviewed the patch.
Patch is excellent in shape and do
Reviewed posted directly on mail thread instead of posting it on commitfest app.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
Personally, I was looking for something like this as I need to see rolename
and namespace name many times in my queries rather than it's oid.
But making a JOIN expression every-time was a pain. This certainly makes it
easier. And I see most DBAs are looking for it.
I agree on Tom's concern on
Hi,
Regarding Loading Custom Format Dump:
===
When we supply plain sql file to pg_restore, we get following error:
$ ./install/bin/pg_restore a.sql
pg_restore: [archiver] input file does not appear to be a valid archive
So I would expect similar kind of message when we provide non-plain sql
file
On Thu, Sep 4, 2014 at 11:41 AM, Pavel Stehule
wrote:
> I am sory
>
> too much patches
>
:)
Patch looks good to me.
Marking "Ready for Committer".
Thanks
>
> Regards
>
> Pavel
>
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise Pos
Hi Pavel,
You have attached wrong patch.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Hi Pavel,
Here are few more comments on new implementation.
1.
/*
- * SQL function row_to_json(row)
+ * SQL function row_to_json(row record, pretty bool, ignore_nulls bool)
*/
In above comments, parameter name "row" should changed to "rowval".
2.
-DATA(insert OID = 3155 ( row_to_json
Hi Pavel,
it needs a redesign of original implementation, we should to change API to
> use default values with named parameters
>
> but it doesn't help too much (although it can be readable little bit more)
>
> instead row_to_json(x, false, true)
>
> be
>
> row_ro_json(x, ignore_null := true)
>
>
Hi Pavel,
Patch does look good to me. And found no issues as such.
However here are my optional suggestions:
1. Frankly, I did not like name of the function "row_to_json_pretty_choosy".
Something like "row_to_json_pretty_ignore_nulls" seems better to me.
2. To use ignore nulls feature, I have t
> I would like to ignore this as UINTMAX lines are too much for a input
> > buffer to hold. It is almost NIL chances to hit this.
>
> Yeah, most likely you will run out of memory before reaching that point,
> or out of patience.
>
> Yep.
BTW, I have marked this as "waiting for committer".
Thanks
Hi Pavel,
You have said that XMLFOREST has something which ignores nulls, what's that?
Will you please provide an example ?
I am NOT sure, but here you are trying to omit entire field from the output
when its value is NULL. But that will add an extra efforts at other end
which is using output of
Hi,
I have reviewed this:
I have initialize cur_lineno to UINTMAX - 2. And then observed following
behaviour to check wrap-around.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[18446744073709551613]=# \set PROMPT2 '%/[%l]%R%# '
postgres[18446744073709551613]=# select
postgres[184467440737095516
Hi,
On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko
wrote:
> >
> >
>
> To my understating cleanly, you means that line number is not changed
> when newline has reached to INT_MAX, is incorrect?
>
As per my thinking yes.
> And the line number should be switched to 1 when line number has
> re
Hi,
Found new issues with latest patch:
> Thank you for reviewing the patch with variable cases.
> I have revised the patch, and attached latest patch.
>
> > A:
> > Will you please explain the idea behind these changes ?
> I thought wrong about adding new to tail of query_buf.
> The latest patch
Hi,
Found few more bugs in new code:
A:
This got bad:
jeevan@ubuntu:~/pg_master$ ./install/bin/psql postgres
psql (9.5devel)
Type "help" for help.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
postgres[1]=# select
postgres[2]-# *
postgres[3]-# from
postgres[4]-#
Hi,
> With further testing I noticed that the patch was not allowing ANTI joins
> in cases like this:
>
> explain select * from a where id not in(select x from b natural join c);
>
>
>
I too found this with natural joins and was about to report that. But its
good that you found that and fixed it
On Sun, Jul 6, 2014 at 10:48 PM, Sawada Masahiko
wrote:
> On Fri, Jun 20, 2014 at 7:17 PM, Jeevan Chalke
> wrote:
> > Hi Sawada Masahiko,
> >
> > I liked this feature. So I have reviewed it.
> >
> > Changes are straight forward and looks perfect.
> > No i
On Sun, Jun 29, 2014 at 4:18 PM, David Rowley wrote:
> I think I'm finally ready for a review again, so I'll update the
> commitfest app.
>
>
I have reviewed this on code level.
1. Patch gets applied cleanly.
2. make/make install/make check all are fine
No issues found till now.
However some c
1 - 100 of 169 matches
Mail list logo
