XID array we check then condition
based on
snapshot->subxcnt. We should check serialized_snapshot->subxcnt rather then
snapshot->subxcnt.
I tried hard to come up with individual test but somehow I was unable to
create testcase.
PFA patch to fix the issue.
regards,
Rushabh Lathia
www.E
On Thu, Jan 7, 2016 at 6:15 PM, Etsuro Fujita
wrote:
> On 2016/01/06 18:58, Rushabh Lathia wrote:
>
>> I started looking at updated patch and its definitely iked the new
>> approach.
>>
>
> Thanks for the review!
>
> With the initial look and test over
On Thu, Jan 14, 2016 at 2:00 PM, Etsuro Fujita
wrote:
> On 2016/01/12 20:31, Rushabh Lathia wrote:
>
>> On Thu, Jan 7, 2016 at 6:15 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> On 2016/01/06 18:58, Rushabh Lathia wrote:
>>
On Fri, Jan 15, 2016 at 9:06 AM, Etsuro Fujita
wrote:
> On 2016/01/14 21:36, Rushabh Lathia wrote:
>
>> On Thu, Jan 14, 2016 at 2:00 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> On 2016/01/12 20:31, Rushabh Lathia wrote:
>&g
On Thu, Jan 21, 2016 at 3:20 PM, Etsuro Fujita
wrote:
> On 2016/01/20 19:57, Rushabh Lathia wrote:
>
>> Overall I am quite done with the review of this patch. Patch is in good
>> shape and covered most of the things which been discussed earlier
>> or been mentioned duri
On Tue, Jan 26, 2016 at 4:15 PM, Etsuro Fujita
wrote:
> On 2016/01/25 17:03, Rushabh Lathia wrote:
>
>> Here are couple of comments:
>>
>
> 1)
>>
>> int
>> IsForeignRelUpdatable (Relation rel);
>>
>
> Documentation for IsFore
On Wed, Jan 27, 2016 at 2:50 PM, Etsuro Fujita
wrote:
> On 2016/01/27 12:20, Etsuro Fujita wrote:
>
>> On 2016/01/26 22:57, Rushabh Lathia wrote:
>>
>>> On Tue, Jan 26, 2016 at 4:15 PM, Etsuro Fujita
>>> mailto:fujita.ets...@lab.ntt.co.jp>>
>>&
On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita wrote:
> On 2016/01/27 21:23, Rushabh Lathia wrote:
>
>> If I understood correctly, above documentation means, that if FDW have
>> DMLPushdown APIs that is enough. But in reality thats not the case, we
>> need ExecForeignI
On Wed, Feb 3, 2016 at 3:31 PM, Etsuro Fujita
wrote:
> On 2016/01/28 15:20, Rushabh Lathia wrote:
>
>> On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>> On 2016/01/27 21:23, Rushabh Lathia wrote:
>
On Wed, Feb 3, 2016 at 3:31 PM, Etsuro Fujita
wrote:
> On 2016/01/28 15:20, Rushabh Lathia wrote:
>
>> On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>> On 2016/01/27 21:23, Rushabh Lathia wrote:
>
On Fri, Feb 5, 2016 at 4:46 PM, Rushabh Lathia
wrote:
>
>
> On Wed, Feb 3, 2016 at 3:31 PM, Etsuro Fujita > wrote:
>
>> On 2016/01/28 15:20, Rushabh Lathia wrote:
>>
>>> On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
>>> mailto:fujita.ets...@lab.ntt
Fujita-san, I am attaching update version of the patch, which added
the documentation update.
Once we finalize this, I feel good with the patch and think that we
could mark this as ready for committer.
On Fri, Feb 5, 2016 at 5:33 PM, Rushabh Lathia
wrote:
>
>
> On Fri, Feb 5, 2016 a
On Fri, Feb 12, 2016 at 5:40 PM, Etsuro Fujita
wrote:
> Hi Rushabh and Thom,
>
> Thanks for the review!
>
> On 2016/02/10 22:37, Thom Brown wrote:
>
>> On 10 February 2016 at 08:00, Rushabh Lathia
>> wrote:
>>
>>> Fujita-san, I am attaching upd
(1 row)
Looking at the code of postgresImportForeignSchema it clear that its not
importing the default expression from the foreign table. But question is
whether it should ?
inputs/thoughts ?
Regards,
Rushabh Lathia
www.EnterpriseDB.com
Oh I just found out that IMPORT FOREIGN do have
import_default and import_not_null options.
Got the answer, sorry for noise.
On Wed, Feb 17, 2016 at 1:31 PM, Rushabh Lathia
wrote:
> Here is the test:
>
> -- create database
> postgres=# create database foo;
> CREATE DATABASE
>
* we could possibly do something more efficient than using
>>> the full
>>> +* expression-eval machinery for this. But probably there
>>> would be little
>>> +* benefit, and it'd require postgres_fdw to know more than is
>>> desirable
&
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
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
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
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
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
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
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
mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Rushabh Lathia
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
(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
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
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 ->
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.
> &
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 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
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
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
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
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
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
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
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
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.
>
>
> --
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
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
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
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
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
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
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
>
> --
> 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
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
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
,
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 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
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 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 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 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 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
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 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,
> >
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
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
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
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
ing to happen.
>
> Regards
>
> Ian Barwick
>
>
> --
> Ian Barwick 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
www.EnterpriseDB.com
;> Hi
>>
>> On 14/06/25 15:13, Rushabh Lathia wrote:
>>
>>> Hello All,
>>>
>>> I assigned my self as reviewer of the patch. I gone through the
>>> mail chain discussion and in that question has been raised about
>>> the feature and
06:14, Gavin Flower > <mailto:gavinflo...@archidevsys.co.nz>> wrote:
>>
>> On 27/06/14 00:12, Rushabh Lathia wrote:
>>
>> INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning
>> primary key, dname;
>>
>>
On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick wrote:
> On 01/07/14 21:00, Rushabh Lathia wrote:
>
>>
>> I spent some more time on the patch and here are my review comments.
>>
>> .) Patch gets applied through patch -p1 (git apply fails)
>>
>> .) trailing
there certainly could be serial columns that weren't in the pkey.
>
>
100% agree with Tom.
> The fact that the spec is kinda fuzzy doesn't entitle us to ignore the
> plain meaning of the term "generated key".
>
> regards, tom lane
>
--
Rushabh Lathia
On Mon, Jul 7, 2014 at 5:50 PM, Robert Haas wrote:
> On Fri, Jul 4, 2014 at 12:36 AM, Rushabh Lathia
> wrote:
> > On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane wrote:
> >> Tom Dunstan writes:
> >> > On 4 July 2014 00:07, Tom Lane wrote:
> >> >>
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
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,
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
> 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
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
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
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
> &
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
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 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
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 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 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
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
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
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
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
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
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
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
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 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
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
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
>
>
-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
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
> >
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 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
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
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
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
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
1 - 100 of 210 matches
Mail list logo
