public inbox for [email protected]  
help / color / mirror / Atom feed
From: Ashesh Vashi <[email protected]>
To: Shirley Wang <[email protected]>
Cc: Robert Eckhardt <[email protected]>
Cc: Akshay Joshi <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Cc: Dave Page <[email protected]>
Subject: Re: Declarative partitioning in pgAdmin4
Date: Wed, 14 Jun 2017 16:11:36 +0530
Message-ID: <CAG7mmozmpra=-WebHe-qWOXp3Tx-W4tLkbXgeSbV5+nuky+Cpw@mail.gmail.com> (raw)
In-Reply-To: <CAPG3WN7aOe=Y2R7qNqHmctZLmwE3eWuqen6Rf7iU-Rq6KeLsUA@mail.gmail.com>
References: <CANxoLDcZND0pjXtrDKRip2xjddzjWiMgY2AMmrqqFE_Yu4+tHw@mail.gmail.com>
	<CA+OCxowUuaNRX9jHmEVFpqT7JCbjn6vaxw+JJ6yrvVp69FZscg@mail.gmail.com>
	<CAPG3WN5NY-Xsa_+6HUQ3NMU_n7jRgJ8L6rjHfyzSLSHS=zZC0Q@mail.gmail.com>
	<CA+OCxoy1v+mq2P4ZL2v7mmyHmjwQmL=v8RR8CSRra_SV96nJDQ@mail.gmail.com>
	<CANxoLDeBGRmq_kUUNNySXimzJO2Ebj0aQBdjNM+0JvP3_Yr9Dw@mail.gmail.com>
	<CAAtBm9Ve2FX4_jY9tv11UqK2BhNoLn118aeT4y=TieSAovL+AA@mail.gmail.com>
	<CA+OCxozkEdTmVUtJEBdHT97EbiUK_+cwW+rv21tuHyxSnN3HOg@mail.gmail.com>
	<CAAtBm9UHyp+bkxcyYL+1qb9knps_cdh6N0tvwMy5uY-eVjWcPg@mail.gmail.com>
	<CANxoLDdgp46uAZzda+cHBn16YibodXgtyH7O1hp39TKT=cv_ig@mail.gmail.com>
	<CA+OCxowpGBLT1q2DzL9VpRG5So8zYssP9SAdd=3Mc6dk8_-p7A@mail.gmail.com>
	<CANxoLDdP945GEfzeYaPjO41D4VoRN2kDMVhHZCOqCXWKegSEHw@mail.gmail.com>
	<CA+OCxowCzLAFybtfnsay9NB0BFORP5yXiitruxh9tvMoADNKRQ@mail.gmail.com>
	<CANxoLDcqudMZ5j-30EcFEL9KpQxyvrMWo0mVrWdg0p6_8e7peQ@mail.gmail.com>
	<CA+OCxow5pXNkDxrL1dbWbheJjpSseefSdvUs5tiwx7k5o3vB7Q@mail.gmail.com>
	<CANxoLDeNovspn8mm0XuYh+F2ShGotwRCAikU5JY9qF1GgFQ9rg@mail.gmail.com>
	<CA+OCxowtH1WJpXA1MKSLrzx_qbKAA36GTEk1t5=3VAS8fegBiA@mail.gmail.com>
	<CANxoLDeLHGvz0NxH_MM7dCe0muA8Sxe54V65b18iHTAESzt97g@mail.gmail.com>
	<CANxoLDeuXKCqrdNwiBut5m7FKQwzRjbPrqR6wHf8qKqgLDnwgQ@mail.gmail.com>
	<CAPG3WN4tiMGoFadBZ9KjB8NfNDVfvDnfUHhS=aya5A0o-jZ3Xw@mail.gmail.com>
	<CANxoLDfN_RvNc0AsVCtrDC-03L53crHzE8JZjmxna3f08KWVqw@mail.gmail.com>
	<CAPG3WN5QA88fNmY4jZZhBY+HUn2FAKecHuvyFjnq2x_vGu4_0w@mail.gmail.com>
	<CANxoLDfjy6sWQVHy5m5Rj1R5_=x_XwPzz6Mndj3xXfnEYpU_zg@mail.gmail.com>
	<CAPG3WN7haKwrQzrgVh7JSunGcP9_6wj=_q_C9J-yYgsZbhWmEw@mail.gmail.com>
	<CANxoLDeZ-izo=RSaHRnFNaAAQjxhd9-x6stx5FyLYU2ZA3A3vA@mail.gmail.com>
	<CAPG3WN6sKefWWYfg9A5=f-QOO9HAsg7krsuQ6FZwvojEuvSjCA@mail.gmail.com>
	<CAAtBm9Xw0qpvqRUb87AoSDdu56iaS8TaoVym3KkBJGjOgLU8cA@mail.gmail.com>
	<CANxoLDegWFzkbUi=8KSL-3cPb0masCjD1HwxaMDhV6fs2uOObw@mail.gmail.com>
	<CAAtBm9VpHahO2pbPM_ATowUU-YLT--RwWHmvW1Q+BtUGiCetyA@mail.gmail.com>
	<CANxoLDc53XkKDO=8FHG1i7KnvPCCiR2-1DjCTQoV9_K4Z11pRQ@mail.gmail.com>
	<CA+OCxoyEAPAra-nkS4qPVYEk3hHyVfRN-FQFPRfjSPrshwhsUg@mail.gmail.com>
	<CAPG3WN72DS8gQmrFR_nBObYaeMaxiqVuyjsVqHaZR1BT4LDqHg@mail.gmail.com>
	<CA+OCxozRODSQ9mdLnJWq4cbgHthQ9EqE7AE80kLbi6YPHBQMYg@mail.gmail.com>
	<CAAtBm9Ua5WMPnXRb87Dr3+FMeuaSWsHSgpYX8AB=TS+PF63pPw@mail.gmail.com>
	<CA+OCxozEKKgCNL9ng7KegYYeFdTU6hy+TdQFBp80W=Ew4XDesg@mail.gmail.com>
	<CAAtBm9V89ndB8ZqU0MPsAsUQ-RMEzbjaG2nFfMmFr1vtaY=v=g@mail.gmail.com>
	<CANxoLDeC9e+=ESBzoCSQeg4zgxwTz5zGG8HwYs9JNr90x4a-tA@mail.gmail.com>
	<CAAtBm9WPFZaeLPUAbZYD3e2d1wyQaP6qUjV-tzEc633Jaguh0w@mail.gmail.com>
	<CAPG3WN6QkAONq4zTU=3tUFJo2a61HGuFY0YbkWRrTSOT7sYObA@mail.gmail.com>
	<CAPG3WN7aOe=Y2R7qNqHmctZLmwE3eWuqen6Rf7iU-Rq6KeLsUA@mail.gmail.com>
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgadmin-hackers>

Hi Shirley,


Please see my reply inline..
On Wed, Jun 14, 2017 at 5:29 AM, Shirley Wang <[email protected]> wrote:

> Some questions/comments/sketches:
>
> - The constraints tab as is implemented now enables constraints for the
> parent table, correct? If so, and if someone wants to apply constraints to
> partitions, as I understand it they would need to apply that to each child
> partition. If that is true, then the tab structure along the top would need
> to change to show constraints only after child partitions are created to
> avoid confusion. OR perhaps at the menu level, have an option for creating
> a partitioned table rather than table.
>
Couple of observation about the table constraints:

- PostgreSQL allow to create CHECK constraint on both partition (parent)
table, and its children partitions.
- Rest of the constraints may not be applicable on the parent table.

So - the question is: whether we should allow to create constraints for the
child partitions from the parent node, or not.

If yes - then:
We will need a switch control (flag) in each of the constraints (in the
subnode control) to distinguish whether the constraint will be applied on
parent/child table.

It think - we can also implement bulk triggers, constraints, indexes from
the parent table, which can be applied to all the children partitions.
We can give these functionality in the

>
> - The steps to create a table with partitions seems to have very clear
> steps. I think it would benefit from a more 'wizard-like' step by step
> flow.
>
Hmm.
Are you saying - we should switch to use the Wizard for table creation?
I think - that should be done in as a separate module.

Any way - we will need to properties dialog for editing the properties of
an existing partition table.

>
> Here's a sketch of a workflow. Just to note, the ellipses are for other
> tabs that might be necessary. I wasn't sure if there were any.
>
> Also, at this point don't worry about buttons versus a dropdown - those
> can change.
>
> *01 fill out general info. User would click next.*
> [image: 02_general.jpg]
>
> *02 User fills out info for columns. Since inheriting columns is not
> possible, we should remove that field entirely.*
> [image: 04_columns.jpg]
>
> *03 User selects partition type from drop down menu.*
>
> [image: 05_partitions.jpg]
>
> *04 Options specific to Range partitions appear (ex. columns and width of
> dates)*
>
> [image: 06_partitions.jpg]
>

I think - there are some details missing.

Here - we're limiting the range/list partition only on one column, which is
clearly wrong.
partition can be any number of columns.

Also - column can be of any type (not just date).

Current implementation (WIP) patch, shared by Akshay, has consider all
those possibilities.

>
> *05 User selects the column they want to partition by from the drop down,
> which should have columns prepopulated as options to choose from.*
> [image: 07_partitions.png]
>
>
> *06 Once the user selects 'Day', 'month', or 'year' partitions, they see a
> loading screen as the app generates partitions*
> [image: 08_partitions.jpg]
>
> *07 Partitions appear below as editable fields if users need to modify
> certain partition names. *
> [image: 09_partitions.jpg]
> *Note: We're assuming that the best naming convention here is the
> [tablename_partitionrange], but this could change. Given that a user might
> be creating tens or hundreds of partitions, this would be valuable to those
> who need a memorable name quickly.*
>
> *08 Constraints*
> Not sure what would need to go on this screen or if it's necessary at this
> level to apply triggers or keys.
>
A parent table can have CHECK constraints.
So - we need the constraints tab.

-- Thanks, Ashesh

>
>
>
>
> Also, here's a link to a clickable mockup if you'd like to try going
> through the app.
> https://pivotal.invisionapp.com/share/6ZC5B0JEM#/238756157_01_General
>
>
> Shirley
>
>
> On Tue, Jun 13, 2017 at 10:28 AM Shirley Wang <[email protected]> wrote:
>
>> To add some interview context - from talking to DBAs, partitioning is the
>> most frequent use case we should account for first. Breaking down child
>> partitions into smaller pieces wasn't something we heard as a need. This is
>> probably not the highest priority work needed now.
>>
>> We should think about when it would be good to release partitioning for
>> some feedback. Did you already have this planned out?
>>
>> On Tue, Jun 13, 2017 at 9:46 AM Robert Eckhardt <[email protected]>
>> wrote:
>>
>>> Akshay,
>>>
>>> Have you determined the minimum feature set you are shooting for before
>>> you commit this? The reason I ask is that we were thinking that some level
>>> of simple automation would probably be nice to make this super useful.
>>>
>>
>>> Basically if you consider a simple example of partitioning 90 days of
>>> data by day the manual process of creating the names and to - from fields
>>> becomes rather painful. If you couple that with potentially wanting to do
>>> list subpartitioning if just multiplies the work.
>>>
>>> If we could get something committed then we could more easily work to
>>> define where simple automation makes sense and where it doesn't.
>>>
>>> -- Rob
>>>
>>> On Tue, Jun 13, 2017 at 6:59 AM, Akshay Joshi <
>>> [email protected]> wrote:
>>>
>>>> Hi All
>>>>
>>>> For further implementation following task needs to be work upon:
>>>>
>>>>    - How to parse and show partitions keys. For example user has
>>>>    created below partitioned table
>>>>
>>>> CREATE TABLE public.sales
>>>> (
>>>>     country character varying COLLATE pg_catalog."default" NOT NULL,
>>>>     sales bigint,
>>>>     saledate date
>>>> ) PARTITION BY RANGE (*country, date_part('year'::text, sale date)*)
>>>>
>>>> When user open the properties dialog I am not able to figure out how
>>>> to parse keys(displayed in bold in above example) and show them in our
>>>> control that we used. For the time being I have hide that control in 'Edit'
>>>> mode (Refer Attach Partition.png)
>>>>
>>>>
>>>>    - *Support of sub partitioning*: To implement sub-partitioning,
>>>>    specify the PARTITION BY clause in the commands used to create individual
>>>>    partitions, for example:
>>>>    -
>>>>
>>>>    CREATE TABLE measurement_y2006 PARTITION OF measurement
>>>>        FOR VALUES FROM ('2006-02-01') TO ('2006-03-01')
>>>>        PARTITION BY RANGE (peaktemp);
>>>>
>>>>
>>>>            To achieve above I have made some changes in GUI (Refer Sub
>>>> Partition.png).
>>>>            *Complex and challenging part here is "measurement_y2006"
>>>> is partition of "measurement" and parent table for other partitions too
>>>> which user can create later. How we will going to show this in browser
>>>> tree? *
>>>>            One option could be
>>>>            Tables
>>>>              ->measurement(table)
>>>>                ->Partitions
>>>>                  ->measurement_y2006(Partition of measurement and
>>>> parent of p1)
>>>>                    ->Partitions
>>>>                      ->p1
>>>>
>>>>    - *Attach Partitions*: To implement attach N partitions I have made
>>>>    some changes in GUI( Refer Attach Partition.png). Attach Partitions
>>>>    control will only be visible in "Edit" mode.
>>>>
>>>> I have only modified the UI changes, there are lots of work needs to
>>>> be done to complete that.
>>>> Please review the design. Suggestions/Comments are welcome.
>>>>
>>>>
>>>> On Tue, Jun 6, 2017 at 4:30 PM, Robert Eckhardt <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 6, 2017 at 4:32 AM, Dave Page <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>> For roll up this pattern seems obvious, identify the n partitions you
>>>>>>> need/want to combine and then run a job to combine them.
>>>>>>>
>>>>>>
>>>>>> You're thinking Greenplum :-). There is no roll up in PostgreSQL,
>>>>>> unless you're thinking we should create such a feature in pgAdmin.
>>>>>>
>>>>>> Of course, I have no objection to extending what we do in PG to add
>>>>>> GP feature support, but let's start with PG.
>>>>>>
>>>>>
>>>>> No not at all. That was a very specific and consistent pattern
>>>>> described by users leveraging time based range partitions in Postgres. I'm
>>>>> not sure if that same use case will be supported with partitioning as
>>>>> implemented in Postgres 10 but it is a Postgres pattern.
>>>>>
>>>>> -- Rob
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> For other patterns such as creating indexes and such it requires a
>>>>>>> bit more thought. Generally users described wanting to treat all of the
>>>>>>> children like a single table (just like Oracle), however, other users
>>>>>>> described potentially modifying chunks of partitions differently depending
>>>>>>> on some criterion. This means that users will need to identify the subset
>>>>>>> they want to optimize and then ideally be able to act on them all at once.
>>>>>>>
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> -- Rob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> So... it sounds like we're on the right lines :-)
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> For the former, this can be addressed by enabling users to modify
>>>>>>>>> one or more child partitions at the same time. For the latter, that is a
>>>>>>>>> workflow that might be addressed outside of the create table with partition
>>>>>>>>> workflow we're working on currently.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jun 5, 2017 at 5:21 AM Dave Page <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Jun 2, 2017 at 9:01 AM, Akshay Joshi <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All
>>>>>>>>>>>
>>>>>>>>>>> Following are the further implementation updates to support
>>>>>>>>>>> Declarative Partitioning:
>>>>>>>>>>>
>>>>>>>>>>>    - Show all the existing partitions of the parent table in
>>>>>>>>>>>    Partitions tab (Refer Existing_Partitions.png)
>>>>>>>>>>>    - Ability to create N partitions and detach existing
>>>>>>>>>>>    partitions. Refer (Create_Detach_Partition.png), in this
>>>>>>>>>>>    example I have detach two existing partition and create two new partitions.
>>>>>>>>>>>    - Added "Detach Partition" menu to partitions node only and
>>>>>>>>>>>    user will be able to detach from there as well. Refer (Detach.
>>>>>>>>>>>    png)
>>>>>>>>>>>
>>>>>>>>>>> That's looking good to me :-)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 24, 2017 at 8:00 PM, Robert Eckhardt <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 24, 2017 at 3:35 AM, Akshay Joshi <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Taking average of two columns is just an
>>>>>>>>>>>>> example/representation of expression, there is no use case of that. As I am
>>>>>>>>>>>>> also in learning phase. Below are some use case that I can think of:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    -
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Partitions based on first letter of their username
>>>>>>>>>>>>>
>>>>>>>>>>>>>    CREATE TABLE users (
>>>>>>>>>>>>>        id             serial not null,
>>>>>>>>>>>>>        username       text not null,
>>>>>>>>>>>>>        password       text,
>>>>>>>>>>>>>        created_on     timestamptz not null,
>>>>>>>>>>>>>        last_logged_on timestamptz not null
>>>>>>>>>>>>>    )PARTITION BY RANGE ( lower( left( username, 1 ) ) );
>>>>>>>>>>>>>    CREATE TABLE users_0
>>>>>>>>>>>>>        partition of users (id, primary key (id), unique (username))
>>>>>>>>>>>>>        for values from ('a') to ('g');
>>>>>>>>>>>>>    CREATE TABLE users_1
>>>>>>>>>>>>>        partition of users (id, primary key (id), unique (username))
>>>>>>>>>>>>>        for values from ('g') to (unbounded);
>>>>>>>>>>>>>
>>>>>>>>>>>>>    -  Partition based on country's sale for each month of an
>>>>>>>>>>>>>    year.
>>>>>>>>>>>>>
>>>>>>>>>>>>> CREATE TABLE public.sales
>>>>>>>>>>>>>
>>>>>>>>>>>>> (
>>>>>>>>>>>>>
>>>>>>>>>>>>>     country text NOT NULL,
>>>>>>>>>>>>>
>>>>>>>>>>>>>     sales bigint NOT NULL,
>>>>>>>>>>>>>
>>>>>>>>>>>>>     saledate date
>>>>>>>>>>>>>
>>>>>>>>>>>>> ) PARTITION BY RANGE (country, (extract (YEAR FROM saledate)),
>>>>>>>>>>>>> (extract(MONTH FROM saledate)))
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> CREATE TABLE public.sale_usa_2017_jan PARTITION OF sales
>>>>>>>>>>>>>
>>>>>>>>>>>>>     FOR VALUES FROM ('usa', 2017, 01) TO ('usa', 2017, 02);
>>>>>>>>>>>>>
>>>>>>>>>>>>> CREATE TABLE public.sale_india_2017_jan PARTITION OF sales
>>>>>>>>>>>>>
>>>>>>>>>>>>>     FOR VALUES FROM ('india', 2017, 01) TO ('india', 2017, 02);
>>>>>>>>>>>>>
>>>>>>>>>>>>> CREATE TABLE public.sale_uk_2017_jan PARTITION OF sales
>>>>>>>>>>>>>
>>>>>>>>>>>>>     FOR VALUES FROM ('uk', 2017, 01) TO ('uk', 2017, 02);
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> INSERT INTO sales VALUES ('india', 10000, '2017-1-15');
>>>>>>>>>>>>>
>>>>>>>>>>>>> INSERT INTO sales VALUES ('uk', 20000, '2017-1-08');
>>>>>>>>>>>>>
>>>>>>>>>>>>> INSERT INTO sales VALUES ('usa', 30000, '2017-1-10');
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Apart from above there may be N number of use cases that
>>>>>>>>>>>>> depends on specific requirement of user.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for the example, you are absolutely correct and we
>>>>>>>>>>>> were confused.
>>>>>>>>>>>>
>>>>>>>>>>>> Given our new found understanding do you mind if we iterate a
>>>>>>>>>>>> bit on the UI/UX?  What we were suggesting with the daily/monthly/yearly
>>>>>>>>>>>> drop down was a specific example of an expression. Given that fact that
>>>>>>>>>>>> doesn't seem to be required in an MVP, however, I do think a more
>>>>>>>>>>>> interactive experience between the definition of the child partitions and
>>>>>>>>>>>> the creation of the partitions would be optimal.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure where you are with respect to implementing the UI
>>>>>>>>>>>> but I'd love to float some ideas and mock ups past you.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Rob
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Akshay Joshi*
>>>>>>>>>>> *Principal Software Engineer *
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91
>>>>>>>>>>> 976-788-8246 <+91%2097678%2088246>*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sent via pgadmin-hackers mailing list (
>>>>>>>>>>> [email protected])
>>>>>>>>>>> To make changes to your subscription:
>>>>>>>>>>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Dave Page
>>>>>>>>>>
>>>>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>>>>> Twitter: @pgsnake
>>>>>>>>>>
>>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dave Page
>>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>>> Twitter: @pgsnake
>>>>>>>>
>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dave Page
>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>> Twitter: @pgsnake
>>>>>>
>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Akshay Joshi*
>>>> *Principal Software Engineer *
>>>>
>>>>
>>>>
>>>> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91
>>>> 976-788-8246 <+91%2097678%2088246>*
>>>>
>>>
>>>


Attachments:

  [image/jpeg] 05_partitions.jpg (118.6K, 3-05_partitions.jpg)
  download | view image

  [image/png] 07_partitions.png (702.8K, 4-07_partitions.png)
  download | view image

  [image/jpeg] 02_general.jpg (145.6K, 5-02_general.jpg)
  download | view image

  [image/jpeg] 06_partitions.jpg (135.7K, 6-06_partitions.jpg)
  download | view image

  [image/jpeg] 08_partitions.jpg (163.6K, 7-08_partitions.jpg)
  download | view image

  [image/jpeg] 09_partitions.jpg (190.5K, 8-09_partitions.jpg)
  download | view image

  [image/jpeg] 04_columns.jpg (194.9K, 9-04_columns.jpg)
  download | view image

view thread (77+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Declarative partitioning in pgAdmin4
  In-Reply-To: <CAG7mmozmpra=-WebHe-qWOXp3Tx-W4tLkbXgeSbV5+nuky+Cpw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox