On Mon, Aug 14, 2017 at 12:40 AM, Rushabh Lathia
wrote:
> 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()
>
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 rewrote it in the attached ve
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 rewrote it in the attached version.
This version also has a bunch of minor cosmetic changes. B
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
> >> option (3)?
> >
> > How about pr
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
>> option (3)?
>
> How about protecting option 2) with the load-via-partition-root protection.
> Me
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
> > and parents to get the root part
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
> and parents to get the root partition TableInfo, but when --schema is been
> specified - it doesn
On Tue, Aug 8, 2017 at 6:18 PM, Rushabh Lathia wrote:
> Thanks Rajkumar for testing and reporting this.
>
>
> It seems like with we set the numParents and parents only for the
> dumpable objects (flagInhTables()). Current patch relies on the numParents
> and parents to get the root partition Table
Thanks Rajkumar for testing and reporting this.
It seems like with we set the numParents and parents only for the
dumpable objects (flagInhTables()). Current patch relies on the numParents
and parents to get the root partition TableInfo, but when --schema is been
specified - it doesn't load those
Hi Rushabh,
While testing latest v2 patch, I got a crash when using
--load-via-partition-root with --schema options. Below are steps to
reproduce.
--create below test data
create schema a;
create schema b;
create schema c;
create table t1 (a int,b text) partition by list(a);
create table a.t1_p1
Here is an update patch, now renamed the switch to
--load-via-partition-root
and also added the documentation for the new switch into pg_dump as well
as pg_dumpall.
On Fri, Aug 4, 2017 at 7:13 AM, Amit Langote
wrote:
> On 2017/08/04 1:08, David G. Johnston wrote:
> > On Thu, Aug 3, 2017 at 8:5
On 2017/08/04 1:08, David G. Johnston wrote:
> On Thu, Aug 3, 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
+1.
Thanks,
Amit
--
Sent via pgsql
On Thu, Aug 3, 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
David J.
Robert Haas writes:
> So maybe --load-via-partition-root if nobody likes my previous
> suggestion of --partition-data-via-root ?
WFM.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Wed, Aug 2, 2017 at 4:08 PM, Peter Eisentraut
wrote:
> On 8/2/17 13:58, Tom Lane wrote:
>> I notice that the option list already includes some references to
>> "insert", so maybe "--insert-via-partition-root"? Although you could
>> argue that that's confusing when we're using COPY.
>
> "load"
On Thu, Aug 3, 2017 at 9:01 AM, Rushabh Lathia wrote:
> --unpartition-partitioned-table is very confusing.
+1.
> I liked the previous option which is --use-partitioned-table
> [partition-name, ...].
> The Only problem with --use-partitioned-table is, a user needs to specify
> the
> partition-nam
On Thursday, August 3, 2017, Rushabh Lathia
wrote:
>
>
> --use-partitioned-table [partitioned_name, ...] # if
> names are omitted 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 loa
On Thu, Aug 3, 2017 at 3:39 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Aug 2, 2017 at 11:47 PM, David G. Johnston
> wrote:
> > On Wed, Aug 2, 2017 at 10:58 AM, Tom Lane wrote:
> >>
> >> Robert Haas writes:
> >> > On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
> >>
On Wed, Aug 2, 2017 at 11:47 PM, David G. Johnston
wrote:
> On Wed, Aug 2, 2017 at 10:58 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>> > On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
>> >> --restore-via-partition-root ?
>>
>> > I worry someone will think that pg_dump is now restoring stuff
On 8/2/17 13:58, Tom Lane wrote:
> I notice that the option list already includes some references to
> "insert", so maybe "--insert-via-partition-root"? Although you could
> argue that that's confusing when we're using COPY.
"load" could be more general. But I'm also OK with "restore".
--
Pete
On Wed, Aug 2, 2017 at 1:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
>>> --restore-via-partition-root ?
>
>> I worry someone will think that pg_dump is now restoring stuff, but it isn't.
>
> Well, the point is that the commands it emits will ca
On Wed, Aug 2, 2017 at 10:58 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
> >> --restore-via-partition-root ?
>
> > I worry someone will think that pg_dump is now restoring stuff, but it
> isn't.
>
> Well, the point is that the commands it emits
Robert Haas writes:
> On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
>> --restore-via-partition-root ?
> I worry someone will think that pg_dump is now restoring stuff, but it isn't.
Well, the point is that the commands it emits will cause the eventual
restore to go through the root. Anyway,
On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> The patch itself looks just fine on a quick glance, modulo the lack of
>> documentation, but I think we need to bikeshed the name of the flag.
>> --reload-through-root is clear as daylight to me, but I'm not sure
>> users wi
Robert Haas writes:
> The patch itself looks just fine on a quick glance, modulo the lack of
> documentation, but I think we need to bikeshed the name of the flag.
> --reload-through-root is clear as daylight to me, but I'm not sure
> users will agree. The lack of the word "partition" is perhaps
On Wed, Aug 2, 2017 at 1:01 AM, Rushabh Lathia wrote:
> Looking at the dbObjectTypePriority comments that seems like data
> restoration
> will *absolutely always* follow all CREATE TABLE commands.
Hmm. I wasn't very convinced by those comments, but Tom's commit
a1ef01fe163b304760088e3e30eb220369
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 the purpose which has been di
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 the purpose which has been discussed in the above
> mentioned thread. But later looking int
https://www.postgresql.org/message-id/CA%2BTgmoZFn7TJ7QBsFat
nuEE%3DGYGdZSNXqr9489n5JBsdy5rFfA%40mail.gmail.com
Above thread, it's been pointed out as important consideration
about adding reload-through-the-top-parent switch the partition
table. One small step toward making use of hash function w
29 matches
Mail list logo