al single-line output, unchanged):
>
> -> Hash (actual rows=100 loops=1)
>Buckets: 131072 Batches: 16 Memory Usage: 3227kB
>-> Seq Scan on simple s (actual rows=100 loops=1)
>
> (It actually says "Tuples Hashed", not "Hashed" but I edited the above
> to fit on a standard punchcard.) Thoughts?
>
> [1] https://www.postgresql.org/message-id/CAEepm%3D2U%2B%
> 2BLp3bNTv2Bv_kkr5NE2pOyHhxU%3DG0YTa4ZhSYhHiw%40mail.gmail.com
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>
--
Rushabh Lathia
mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
On Wed, Sep 20, 2017 at 5:17 AM, Peter Geoghegan wrote:
> On Tue, Sep 19, 2017 at 3:21 AM, Rushabh Lathia
> wrote:
> > As per the earlier discussion in the thread, I did experiment using
> > BufFileSet interface from parallel-hash-v18.patchset. I took the
> reference
>
On Mon, Sep 18, 2017 at 2:48 PM, Amit Kapila
wrote:
> On Mon, Sep 18, 2017 at 12:46 PM, Rushabh Lathia
> wrote:
> > Thanks Amit for the patch.
> >
> > I reviewed the code changes as well as performed more testing. Patch
> > looks good to me.
> >
>
> I
Thanks Amit for the patch.
I reviewed the code changes as well as performed more testing. Patch
looks good to me.
Here is the updated patch - where added test-case clean up.
On Thu, Sep 14, 2017 at 10:02 AM, Amit Kapila
wrote:
> On Wed, Sep 13, 2017 at 5:30 PM, Rushabh Lathia
>
n I can add regression
> tests to cover above cases in the patch.
>
> [1] - https://www.postgresql.org/message-id/CAA4eK1Ji_
> 0pgrjFotAyvvfxGikxJQEKcxD863VQ-xYtfQBy0uQ%40mail.gmail.com
Sure, once you do that - I will review the patch.
Thanks,
>
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
Okay, I have marked this as ready for committer.
Thanks,
On Wed, Sep 6, 2017 at 2:50 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia
> wrote:
> >
> > 2) Add partition to the foo;
> >
> > crea
think the
> > original is fine.
> >
>
> We have used this style in the "else" case of if (!verbose). So, I
> just copied it. I have removed that change in the attached patch.
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postg
4) (
> actual time=0.015..0.019 rows=1 loops=1)
> Filter: ((id = 1) OR (id = 5))
> Rows Removed by Filter: 6
>-> Seq Scan on h3 (cost=0.00..48.25 rows=25 width=4) (
> actual time=0.005..0.010 rows=1 loops=1)
> Filter: ((id = 1) OR (id = 5))
> Rows Removed by Filter: 3
> Planning time: 0.396 ms
> Execution time: 0.139 ms
> (9 rows)
>
> Can not detach / attach / drop partition table.
>
> Best regards,
> young
>
> --
>
> https://yonj1e.github.io/
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
On Fri, Aug 11, 2017 at 10:50 PM, Robert Haas wrote:
> On Fri, Aug 11, 2017 at 5:36 AM, Rushabh Lathia
> wrote:
> > Please find attach patch with the changes.
>
> I found the way that you had the logic structured in flagInhTables()
> to be quite hard to follow, so I rewro
On Thu, Aug 10, 2017 at 8:26 PM, Robert Haas wrote:
> On Thu, Aug 10, 2017 at 3:47 AM, Rushabh Lathia
> wrote:
> >> (1) seems like a pretty arbitrary restriction, so I don't like that
> >> option. (2) would hurt performance in some use cases. Do we have an
>
On Wed, Aug 9, 2017 at 1:20 AM, Robert Haas wrote:
> On Tue, Aug 8, 2017 at 8:48 AM, Rushabh Lathia
> wrote:
> > It seems like with we set the numParents and parents only for the
> > dumpable objects (flagInhTables()). Current patch relies on the
> numParents
> >
-Fp
> [edb@localhost bin]$ ./pg_dump -d postgres --load-via-partition-root
> --schema=a -f d3.dump -Fp
> pg_dump: pg_dump.c:2063: getRootTableInfo: Assertion `tbinfo->numParents
> == 1' failed.
> Aborted (core dumped)
>
>
>
> Thanks & Regards,
> Rajkumar R
2017 at 8:53 AM, Tom Lane wrote:
> >
> >> Robert Haas writes:
> >>> So maybe --load-via-partition-root if nobody likes my previous
> >>> suggestion of --partition-data-via-root ?
> >>
> >> WFM.
> >>
> >
> > +1
>
>
ted it defaults to all the partitioned tables.
Here user need to specify the root relation name in the option - and any
partition table have that as a ROOT, will load the data through
top-parent-relation.
That really says what dump is really doing without focusing on how the
> data will be used like restoring/inserting/copying etc.
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>
--
Rushabh Lathia
On Wed, Aug 2, 2017 at 3:55 AM, Robert Haas wrote:
> On Tue, Aug 1, 2017 at 5:34 AM, Rushabh Lathia
> wrote:
> > My colleague Robert and I had doubt about the order in of TABLE
> > and TABLE_DATA. We thought earlier that reload-thought-root might
> > might not solve th
might
might not solve the purpose which has been discussed in the above
mentioned thread. But later looking into code I realize the sort order
for DO_TABLE and DO_TABLE_DATA are different, so we don't need
to worry about that issue.
TODOs:
- Update documentation for pg_dump & pg_dumpall
T
On Tue, Jul 25, 2017 at 7:43 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
> >> Some looking around says that this *isn't* the only place that just
> >> blithely assumes that it will find an opfamily entry. Bu
On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > PFA patch, where added elog() to add the error message same as all other
> > places.
>
> Some looking around says that this *isn't* the only place that just
> blithely assumes that it will
the other
places where get_opfamily_proc() unable to find valid function oid.
PFA patch, where added elog() to add the error message same as all other
places.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
ind
n see the hidden
rows in the pg_dump output.
./db/bin/pg_dump -U rls_test_user1 postgres --inserts
Attaching the dump output.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
--
-- PostgreSQL database dump
--
-- Dumped from database version 10beta1
-- Dumped by pg_dump version 10beta1
SET stateme
mplicated.
>
> --
> Regards,
> Dilip Kumar
> EnterpriseDB: http://www.enterprisedb.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
27;s even a workable solution. Just trying to think of ways
> around the current limitations and still allow this feature.
>
I like the idea about having DEFAULT partition for the range partition.
With the
way partition is designed it can have holes into range partition. I think
DEFAULT
for the range partition is a good idea, generally when the range having
holes. When
range is serial then of course DEFAULT partition doen't much sense.
Regarda,
Rushabh Lathia
www.EnterpriseDB.com
ow-movement,
then we might add that under some GUC or may be as another option into
the CREATE partition table.
Could you briefly elaborate why you think the lack global index support
> would be a problem in this regard?
>
> I agree that some design is required here to implement a solution
> redistribution of rows; not only in the context of supporting the notion
> of default partitions, but also to allow the feature to split/merge range
> (only?) partitions. I'd like to work on the latter for v11 for which I
> would like to post a proposal soon; if anyone would like to collaborate
> (ideas, code, review), I look forward to. (sorry for hijacking this
> thread.)
>
> Thanks,
> Amit
>
>
>
--
Rushabh Lathia
Hi,
On Mon, Apr 3, 2017 at 10:56 AM, Rushabh Lathia
wrote:
>
>
> On Sat, Apr 1, 2017 at 7:58 PM, Robert Haas wrote:
>
>> On Fri, Mar 31, 2017 at 10:26 PM, Andres Freund
>> wrote:
>> > Hi,
>> >
>> > On 2017-04-01 01:22:14 +, Robert Haas
eDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
On Wed, Mar 29, 2017 at 8:38 AM, Tomas Vondra
wrote:
> Hi,
>
> On 03/28/2017 11:07 AM, Rushabh Lathia wrote:
>
>> ...
>> I think we all agree that we should get rid of nreaders from the
>> GatherMergeState and need to do some code re-factor. But if I
>> unders
On Tue, Mar 28, 2017 at 10:00 AM, Tomas Vondra wrote:
>
>
> On 03/27/2017 01:40 PM, Rushabh Lathia wrote:
>
>>
>> ...
>> I was doing more testing with the patch and I found one more server
>> crash with the patch around same area, when we forced the gather
&g
On Mon, Mar 27, 2017 at 9:52 PM, Robert Haas wrote:
> On Mon, Mar 27, 2017 at 12:11 PM, David Rowley
> wrote:
> > On 28 March 2017 at 04:57, Robert Haas wrote:
> >> On Sat, Mar 25, 2017 at 12:18 PM, Rushabh Lathia
> >> wrote:
> >>> About the or
On Mon, Mar 27, 2017 at 10:59 AM, Rushabh Lathia
wrote:
>
>
> On Mon, Mar 27, 2017 at 3:43 AM, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote:
>
>> On 03/25/2017 05:18 PM, Rushabh Lathia wrote:
>>
>>>
>>>
>>> On Sat, Mar 25, 20
you,
> Rahila Syed
>
> On Tue, Mar 21, 2017 at 11:36 AM, Rushabh Lathia > wrote:
>
>> I picked this for review and noticed that patch is not getting
>> cleanly complied on my environment.
>>
>> partition.c: In function ‘RelationBuildPartitionDesc’:
>>
On Mon, Mar 27, 2017 at 3:43 AM, Tomas Vondra
wrote:
> On 03/25/2017 05:18 PM, Rushabh Lathia wrote:
>
>>
>>
>> On Sat, Mar 25, 2017 at 7:01 PM, Peter Eisentraut
>> > <mailto:peter.eisentr...@2ndquadrant.com>> wrote:
>>
>> On 3/25/17 09:0
On Sat, Mar 25, 2017 at 7:01 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/25/17 09:01, David Rowley wrote:
> > On 25 March 2017 at 23:09, Rushabh Lathia
> wrote:
> >> Also another point which I think we should fix is, when someone set
> &
http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
psql: Add completion for \help DROP|ALTER
PFA patch to fix the same.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index f749406..02a1571 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -999,8
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
some unused code and the no longer useful dblink.h file.
Reviewed-by: Tsunakawa, Takayuki
Before this, macro used to assign the conname local variable; I quickly
worked
on the fix and attached patch do fix the issues. Patch assign the conname
local variable, so that error context show the c
e_ordered_paths,
which is wrong. Into create_ordered_paths(), GM should not consider the
limit
while doing costing for the sort node.
Attached patch fix the bug.
On Wed, Mar 22, 2017 at 12:05 PM, Rushabh Lathia
wrote:
> Thanks for reporting, I am looking into this.
>
> On Wed, Mar 22,
rt Memory: 25kB
> > -> Seq Scan on test (cost=0.00..15406.00 rows=100
> > width=16) (actual time=0.085..107.522 rows=100 loops=1)
> > Planning time: 0.093 ms
> > Execution time: 211.608 ms
> > (7 rows)
> >
> >
> >
> > --
> > Thanks and Regards
> > Mithun C Y
> > EnterpriseDB: http://www.enterprisedb.com
>
>
>
> --
> Thanks and Regards
> Mithun C Y
> EnterpriseDB: http://www.enterprisedb.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
titioning constraints correct and consistently enforcing them, just
>> as for any other partition.
>>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
On Sat, Mar 18, 2017 at 5:15 PM, Robert Haas wrote:
> On Fri, Mar 17, 2017 at 10:01 AM, Rushabh Lathia
> wrote:
> > I tried to cover all the suggestion in the attached latest patch.
>
> Committed. I reworded the documentation entries, renamed a few of the
> wait event
ybe?
>
>
DSMFillZeroWrite? Basically want to keep the file IP operation at the end of
the event name.
> Of course the constants should be renamed to match.
>
I tried to cover all the suggestion in the attached latest patch.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
diff --git a
ng called during the ALTER SYSTEM call. Here
write
happen only when someone explicitly run the ALTER SYSTEM call. This is
administrator call and so doesn't seem like necessary to add separate wait
event
for this.
PFA latest patch with other fixes.
>
> On Wed, Mar 8, 2017 at 4:50 PM, Ru
On Mon, Mar 13, 2017 at 10:56 PM, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 7:59 AM, Rushabh Lathia
> wrote:
> > Error coming from create_gather_merge_plan() from below condition:
> >
> > if (memcmp(sortColIdx, gm_plan->sortColIdx,
> >
8}
- Attached memory watch point and found that target list for GatherMerge is
getting
changed into groupping_planner() -> apply_projection_to_path().
PFA patch to fix this issue.
On Fri, Mar 10, 2017 at 4:12 PM, Rushabh Lathia
wrote:
>
>
> On Fri, Mar 10, 2017 at 4:09 PM, Kuntal G
On Fri, Mar 10, 2017 at 4:09 PM, Kuntal Ghosh
wrote:
> On Fri, Mar 10, 2017 at 3:04 PM, Rushabh Lathia
> wrote:
> >
> >
> > On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh <
> andr...@visena.com>
> > wrote:
> >>
> >> P
On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh
wrote:
> På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia <
> rushabh.lat...@gmail.com>:
>
>
>
> On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh
> wrote:
>>
>> [...]
>> The execu
On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh
wrote:
> På fredag 10. mars 2017 kl. 09:53:47, skrev Rushabh Lathia <
> rushabh.lat...@gmail.com>:
>
>
>
> On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh
> wrote:
>>
>> På torsdag 09. ma
On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh
wrote:
> På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas <
> robertmh...@gmail.com>:
>
> On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia
> wrote:
> > I don't see this failure with the patch. Even I fo
On Thu, Mar 9, 2017 at 9:42 PM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 8:21 AM, Rushabh Lathia
> wrote:
> > Thanks Robert for committing this.
> >
> > My colleague Neha Sharma found one regression with the patch. I was about
> > to send this mail and notice
On Thu, Mar 9, 2017 at 6:19 PM, Robert Haas wrote:
> On Wed, Mar 8, 2017 at 11:59 PM, Rushabh Lathia
> wrote:
> > Here is another version of patch with the suggested changes.
>
> Committed.
>
>
Thanks Robert for committing this.
My colleague Neha Sharma found one regr
,
WriteXLog,
ReadDataBlock
On Wed, Mar 8, 2017 at 6:41 PM, Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
> On Wed, Mar 8, 2017 at 4:50 PM, Rushabh Lathia
> wrote:
>
>> I am attaching another version of the patch, as I found stupid mistake
>> in t
On Thu, Mar 9, 2017 at 8:40 AM, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 1:35 AM, Rushabh Lathia
> wrote:
> > Thanks Amit for raising this point. I was not at all aware of
> mark/restore.
> > I tried to come up with the case, but haven't found such case.
> &g
ation, and later of end up into situation where we re-think about
adding those missing stuff is not good. Having more information about
the system, specially for monitoring purpose is always good.
I am attaching another version of the patch, as I found stupid mistake
in the earlier versio
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
gt; On Thu, Mar 2, 2017 at 6:06 PM, Rushabh Lathia <
> rushabh.lat...@gmail.com> wrote:
> >>> While reading through the cost_agg() I found that startup cost for the
> >>> group aggregate is not correctly assigned. Due to this explain plan is
> >>> not pri
On Sat, Mar 4, 2017 at 7:53 PM, Amit Kapila wrote:
> On Mon, Feb 20, 2017 at 4:04 PM, Rushabh Lathia
> wrote:
> >
> > My colleague Rahila reported compilation issue with
> > the patch. Issue was only coming with we do the clean
> > build on the branch.
> >
&g
Sort Key: aid
-> Seq Scan on pgbench_accounts (cost=0.00..61487.89 rows=198155
width=8)
Filter: (filler ~~ '%foo%'::text)
(6 rows)
PFA patch to correct the same.
Regards,
Rushabh Lathia
www.EnterpriseDB.com
fix_startup_cost_cost_agg.patch
Description: appl
hint4(10))%3;
> QUERY PLAN
> --
> Append (cost=0.00..61.00 rows=14 width=4)
>-> Seq Scan on h (cost=0.00..0.00 rows=1 width=4)
> Filter: ((abs(hashint4(i)) % 3) = 2)
>-> Seq Scan on h3 (cost=0.00..61.00 rows=13 width=4)
> Filter: ((abs(hashint4(i)) % 3) = 2)
> (5 rows)
>
> Best regards,
> Yugo Nagata
>
> --
> Yugo Nagata
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
Regards,
Rushabh Lathia
On Wed, Feb 22, 2017 at 12:15 PM, Etsuro Fujita wrote:
> On 2017/02/21 19:31, Rushabh Lathia wrote:
>
>> On Mon, Feb 20, 2017 at 1:41 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> On 2017/02/13 18:24, Rushabh Lathia wro
On Mon, Feb 20, 2017 at 1:41 PM, Etsuro Fujita
wrote:
> On 2017/02/13 18:24, Rushabh Lathia wrote:
>
>> I started reviewing the patch again. Patch applied cleanly on latest
>> source
>> as well as regression pass through with the patch. I also performed
>> few ma
My colleague Rahila reported compilation issue with
the patch. Issue was only coming with we do the clean
build on the branch.
Fixed the same into latest version of patch.
Thanks,
On Tue, Jan 31, 2017 at 11:09 AM, Rushabh Lathia
wrote:
>
>
> On Tue, Jan 31, 2017 at 8:54 AM, Michae
e are not clear what kind of
> benefits we can get via mark/restore support for GatherMerge, it
> doesn't make much sense to take the trouble of implementing it.
>
> >
> > A comment update is probably a good idea, though.
> >
>
> Agreed.
>
>
> --
On Fri, Feb 17, 2017 at 4:47 PM, Amit Kapila
wrote:
> On Fri, Feb 17, 2017 at 3:59 PM, Thomas Munro
> wrote:
> > On Thu, Feb 2, 2017 at 2:32 AM, Rushabh Lathia
> wrote:
> >> Please find attached latest patch.
> >
> > The latest patch still appl
On Fri, Feb 17, 2017 at 3:59 PM, Thomas Munro wrote:
> On Thu, Feb 2, 2017 at 2:32 AM, Rushabh Lathia
> wrote:
> > Please find attached latest patch.
>
> The latest patch still applies (with some fuzz), builds and the
> regression tests pass.
>
> Attached latest patc
he fdw_scan_tlist to postgres_fdw.c,
> > added/revised comments, and added regression tests for the case where a
> > pushed down UPDATE/DELETE on a join has RETURNING.
> >
> > My apologies for having been late to work on this.
>
> Moved to CF 2017-03.
> --
> Michael
>
--
Rushabh Lathia
rallel jobs" error.
if (opts->number_of_jobs <= 0)
{
fprintf(stderr, _("%s: invalid number of parallel jobs\n"),
progname);
exit(1);
}
Please find attach patch to initialize default value for number of jobs to
1.
Thanks,
Rushabh Lathia
www.
Wed, Feb 1, 2017 at 5:55 PM, Rushabh Lathia
wrote:
> I am sorry for the delay, here is the latest re-based patch.
>
> my colleague Neha Sharma, reported one regression with the patch, where
> explain output for the Sort node under GatherMerge was always showing
> cost as zero:
>
963 ms
This patch also fix that issue.
On Wed, Feb 1, 2017 at 11:27 AM, Michael Paquier
wrote:
> On Mon, Jan 23, 2017 at 6:51 PM, Kuntal Ghosh
> wrote:
> > On Wed, Jan 18, 2017 at 11:31 AM, Rushabh Lathia
> > wrote:
> >>
> > The patch needs a rebase after
On Tue, Jan 31, 2017 at 8:54 AM, Michael Paquier
wrote:
> On Mon, Jan 30, 2017 at 10:01 PM, Rushabh Lathia
> wrote:
> > Attached is the patch, which extend the existing wait event
> infrastructure
> > to implement the wait events for the disk I/O. Basically
> pg_stat_a
_info.
Thanks to my colleague Robert Haas for his help in design.
Please let me know your thought, and thanks for reading.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
wait_event_disk_IO.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, Jan 28, 2017 at 3:43 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia
> wrote:
>
>> Consider the below test;
>>
>> CREATE TABLE tab ( a int primary key);
>>
>> SELECT *
>> FRO
168ae006929eec44fc44d569e846b9. It seems
check_srf_call_placement() sets the hasTargetSRFs flag and but when the SRFs
at the rtable ofcourse this flag doesn't get set. It seems like missing
something
their, but I might be completely wrong as not quire aware of this area.
regards,
Rushabh Lathia
www.EnterpriseDB.com
On Tue, Jan 17, 2017 at 6:44 PM, Amit Kapila
wrote:
> On Tue, Jan 17, 2017 at 5:19 PM, Rushabh Lathia
> wrote:
> >
> >
> >
> > Here is the benchmark number which I got with the latest (v6) patch:
> >
> > - max_worker_processes = DEFAULT (8)
> >
On Tue, Jan 17, 2017 at 5:19 PM, Rushabh Lathia
wrote:
>
>
> On Fri, Jan 13, 2017 at 10:52 AM, Rushabh Lathia > wrote:
>
>>
>>
>> On Thu, Jan 12, 2017 at 8:50 AM, Robert Haas
>> wrote:
>>
>>> On Sun, Dec 4, 2016 at 7:36 PM, Haribabu Ko
On Fri, Jan 13, 2017 at 10:52 AM, Rushabh Lathia
wrote:
>
>
> On Thu, Jan 12, 2017 at 8:50 AM, Robert Haas
> wrote:
>
>> On Sun, Dec 4, 2016 at 7:36 PM, Haribabu Kommi
>> wrote:
>> > On Thu, Nov 24, 2016 at 11:12 PM, Rushabh Lathia <
>> rushabh.l
On Thu, Jan 12, 2017 at 8:50 AM, Robert Haas wrote:
> On Sun, Dec 4, 2016 at 7:36 PM, Haribabu Kommi
> wrote:
> > On Thu, Nov 24, 2016 at 11:12 PM, Rushabh Lathia <
> rushabh.lat...@gmail.com>
> > wrote:
> >> PFA latest patch with fix as well as few cosmet
On Wed, Nov 16, 2016 at 3:10 PM, Rushabh Lathia
wrote:
>
>
> On Mon, Nov 14, 2016 at 3:51 PM, Thomas Munro <
> thomas.mu...@enterprisedb.com> wrote:
>
>> On Sat, Nov 12, 2016 at 1:56 AM, Rushabh Lathia
>> wrote:
>> > On Fri, Nov 4, 20
On Tue, Nov 22, 2016 at 6:24 PM, Etsuro Fujita
wrote:
> Hi Rushabh,
>
> On 2016/11/22 19:05, Rushabh Lathia wrote:
>
>> I started reviewing the patch and here are few initial review points and
>> questions for you.
>>
>
> Thanks for the review!
>
> 1)
olean
> value (either infinite or not) and to distinguish +infinity from
> -infinity, we looked at whether the bound is lower or upper (the lower
> flag). Now, instead, the variable holding the status of individual range
> bound datum is set to a ternary value: RANGE_DATUM_FINITE (0),
> RANGE_DATUM_NEG_INF (1), and RANGE_DATUM_POS_INF (2), which still fits in
> a bool. Upon encountering an infinite range bound datum, whether it's
> negative or positive infinity derives the comparison result. Consider the
> following example:
>
> partition p1 from (1, unbounded) to (1, 1);
> partition p2 from (1, 1) to (1, 10);
> partition p3 from (1, 10) to (1, unbounded);
> partition p4 from (2, unbounded) to (2, 1);
> ... so on
>
> In this case, we need to be able to conclude, say, (1, -inf) < (1, 15) <
> (1, +inf), so that tuple (1, 15) is assigned to the proper partition.
>
> Does this last thing sound reasonable?
>
> Thanks,
> Amit
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
g
>>> upon the status of this patch. Does that make sense?
>>>
>>
> OK, I'll extract from the patch the minimal part that wouldn't depend on
>> the two patches.
>>
>
> Here is a patch for that. Todo items are: (1) add more comments and (2)
> add more regression tests. I'll do that in the next version.
>
> Best regards,
> Etsuro Fujita
>
--
Rushabh Lathia
On Mon, Nov 14, 2016 at 3:51 PM, Thomas Munro wrote:
> On Sat, Nov 12, 2016 at 1:56 AM, Rushabh Lathia
> wrote:
> > On Fri, Nov 4, 2016 at 8:30 AM, Thomas Munro <
> thomas.mu...@enterprisedb.com>
> > wrote:
> >> + * Portions Copyright (c) 1996-2015, P
ated on top of the patch set [1]. The patch is still WIP (ie,
> needs more comments and regression tests, at least), but any comments would
> be gratefully appreciated.
>
> Best regards,
> Etsuro Fujita
>
> [1] https://www.postgresql.org/message-id/11eafd10-d3f8-ac8a-b64
> 2-b0e65037c76b%40lab.ntt.co.jp
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
Oops forgot to attach latest patch in the earlier mail.
On Fri, Nov 11, 2016 at 6:26 PM, Rushabh Lathia
wrote:
>
>
> On Fri, Nov 4, 2016 at 8:30 AM, Thomas Munro <
> thomas.mu...@enterprisedb.com> wrote:
>
>> On Thu, Oct 27, 2016 at 10:50 PM, Rushabh Lathia
On Fri, Nov 4, 2016 at 8:30 AM, Thomas Munro
wrote:
> On Thu, Oct 27, 2016 at 10:50 PM, Rushabh Lathia
> wrote:
> > Please find attached latest patch which fix the review point as well as
> > additional clean-up.
>
> I've signed up to review this patch and I&#x
patch and I haven't
observed any regression. Some of TPC-H queries showing additional benefit
with
the latest patch, but its just under 5%.
Do let me know if I missed anything.
On Mon, Oct 24, 2016 at 11:55 AM, Rushabh Lathia
wrote:
>
>
> On Thu, Oct 20, 2016 at 1:12 PM, Amit K
On Thu, Oct 20, 2016 at 1:12 PM, Amit Kapila
wrote:
> On Tue, Oct 18, 2016 at 5:29 PM, Rushabh Lathia
> wrote:
> > On Mon, Oct 17, 2016 at 2:26 PM, Amit Kapila
> > wrote:
> >>
> >> There is lot of common code between ExecGatherMerge and ExecGather.
> &
On Thu, Oct 20, 2016 at 12:22 AM, Peter Geoghegan wrote:
> On Tue, Oct 4, 2016 at 11:05 PM, Rushabh Lathia
> wrote:
> > Query 4: With GM 7901.480 -> Without GM 9064.776
> > Query 5: With GM 53452.126 -> Without GM 55059.511
> > Query 9: With GM 52613.132 ->
Thanks Amit for reviewing this patch.
On Mon, Oct 17, 2016 at 2:26 PM, Amit Kapila
wrote:
> On Wed, Oct 5, 2016 at 11:35 AM, Rushabh Lathia
> wrote:
> > Hi hackers,
> >
> > Attached is the patch to implement Gather Merge.
> >
>
> Couple of revie
(and then probably
> renaming the column, since it isn't actually source code in that case).
>The argument is over what to do for PL functions, which is only one use
> case not two
Thinking more, I am good for keeping prosrc in \df+ for internal/C-language
functions (with changed column
e" as part of \df+ output (irrespective of
language) is still very much useful for the people - it make sense
not to change it at all. Also agree with Stephen view that once we do
end up improving \sf - we may be re-consider removing source code
from the \df+ output. For now we should stick with the goal for a thread
that started out being about showing parallel status in \df+ output.
> Thanks!
>
> Stephen
>
--
Rushabh Lathia
www.EnterpriseDB.com
users
> probably initially felt mollycoddled when they first encountered the
> error but I'm sure that some were secretly glad of its existence from
> time to time... I think it's a useful feature for users who want it,
> and a nice little demonstration of how extensible Postgres is.
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > I agree with the argument in this thread, having "Source code" as part
> > of \df+ is bit annoying, specifically when output involve some really
> > big PL language functions. Having is
ther approach for implementing direct modification, I like
the
idea of modifying the document.
I agree that the documentation about how the FDW author should decide
> between the two would be helpful, but I'd like to leave that for future
> work.
>
I performed basic test with patch,
a) patch get applied cleanly on latest source,
b) able to build documentation cleanly.
Marking this as ready for committer.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
ng so using footer for this purpose is not too great idea -
> maybe we can live better without it (without source code of PL in \dt+
> result, I would to see only C function source there). If you like using
> footer, then the format should be changed to be more consistent, readable?
> I am not sure, how it can be enhanced.
>
> Regards
>
> Pavel
>
>
>>
>> regards, tom lane
>>
>
>
--
Rushabh Lathia
ned on inside a
> transaction. But only when there is an implicit BEGIN as in following case,
>
> postgres=# \set AUTOCOMMIT OFF
> postgres=# create table test(i int);
> CREATE TABLE
> postgres=# \set AUTOCOMMIT ON
> \set: Cannot set AUTOCOMMIT to ON inside a transaction, either COMMIT or
> ROLLBACK and retry
> postgres=#
>
> Thank you,
> Rahila Syed
>
>
Regards,
Rushabh Lathia
www.EnterpriseDB.com
k all the previous commands.
>>
>> A server error would do that, but a psql errror won't.
>>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Rushabh Lathia
t; allocated in the same context as the regular instrumentation
> information, which I assume is probably the per-query context.
>
I agree, this make sense.
Here is the patch to allocate worker instrumentation into same context
as the regular instrumentation which is per-query context.
PFA patch.
eaders or
just pfree(planstate->reader) into gather_readnext() instead of calling
ExecShutdownGatherWorkers().
2) Teach ExecParallelRetrieveInstrumentation() to do allocation of
planstate->worker_instrument into proper memory context.
Attaching patch, which fix the issue with approach 1).
Regards.
Rushab
Thanks Tom.
I performed testing with the latest commit and test are
running fine.
On Tue, Jun 28, 2016 at 8:14 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > SELECT setval('s', max(100)) from tab;
> > ERROR: ORDER/GROUP BY expression not found in targetlist
>
&g
1 - 100 of 210 matches
Mail list logo
