On Mon, Apr 3, 2017 at 12:52 AM, Amit Langote
wrote:
> I noticed what looks like a redundant line (or an incomplete sentence) in
> the paragraph about multi-column partition keys. In the following text:
>
> + partitioning, if desired. Of course, this will often result in a
> larger
> +
On 2017/04/01 6:37, Robert Haas wrote:
> On Tue, Mar 28, 2017 at 6:35 AM, Amit Langote
> wrote:
>> Attached updated patch.
>
> Committed with editing here and there. I just left out the thing
> about UNION ALL views, which seemed to brief a treatment to deserve
> its own subsection. Maybe a lon
On Tue, Mar 28, 2017 at 6:35 AM, Amit Langote
wrote:
> Attached updated patch.
Committed with editing here and there. I just left out the thing
about UNION ALL views, which seemed to brief a treatment to deserve
its own subsection. Maybe a longer explanation of that is worthwhile
or maybe it's
On 2017/03/28 0:23, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 8:23 PM, Amit Langote wrote:
>> Attached updated patches.
>
> Committed 0002, 0003.
Thanks a lot for committing these and reviewing 0001.
> I think the section on BRIN in 0001 is just silly. BRIN is a very
> useful index type, poss
On Thu, Mar 9, 2017 at 8:23 PM, Amit Langote
wrote:
> On 2017/03/10 3:26, Robert Haas wrote:
>> I think you might have the titles for 0002 and 0003 backwards.
>
> Oops, you're right.
>
>> On Fri, Mar 3, 2017 at 2:51 AM, Amit Langote wrote:
>>> 0002: some cosmetic fixes to create_table.sgml
>>
>> I
On 2017/03/10 3:26, Robert Haas wrote:
> I think you might have the titles for 0002 and 0003 backwards.
Oops, you're right.
> On Fri, Mar 3, 2017 at 2:51 AM, Amit Langote wrote:
>> 0002: some cosmetic fixes to create_table.sgml
>
> I think this sentence may be unclear to some readers:
>
> + One
Robert Haas writes:
> This is about list-ifying a note, but I think we should try to
> de-note-ify it. It's a giant block of text that is not obviously more
> noteworthy than the surrounding text; I think should be saved
> for things that particularly need to be called out.
Yeah. A big problem
I think you might have the titles for 0002 and 0003 backwards.
On Fri, Mar 3, 2017 at 2:51 AM, Amit Langote
wrote:
> 0002: some cosmetic fixes to create_table.sgml
I think this sentence may be unclear to some readers:
+ One might however want to set it for only some partitions,
+ which is
On 2017/02/28 17:25, Simon Riggs wrote:
> On 28 February 2017 at 08:14, Amit Langote
> wrote:
>
>> OK. So, I will start writing the patch with above general skeleton and
>> hopefully post it within this week and you can improve it as fit.
>
> Will do, thanks.
Attached patch 0001 is what I mana
On Mon, Feb 27, 2017 at 5:14 PM, Simon Riggs wrote:
>> I like the idea of merging what are now two chapters into one and call it
>> Partitioned Tables, retaining the text that describes concepts
>
> +1
>
> ...but how?
>
> 5.10 Partitioned Tables and Related Solutions
> 5.10.1 Declarative Partition
On 28 February 2017 at 08:14, Amit Langote
wrote:
> OK. So, I will start writing the patch with above general skeleton and
> hopefully post it within this week and you can improve it as fit.
Will do, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On 2017/02/27 20:44, Simon Riggs wrote:
> On 27 February 2017 at 10:12, Amit Langote
> wrote:
>
>> I agree that my patch failed to de-emphasize the old partitioning method
>> enough. The examples in 5.11 Partitioning chapter also did not highlight
>> the new partitioning feature as much as it sh
On 27/02/17 07:59, Amit Langote wrote:
> On 2017/02/27 3:18, Petr Jelinek wrote:
>> On 24/02/17 07:15, Robert Haas wrote:
>>> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote:
The good news is that logical replication DOES work with partitioning,
but only for a Publication with PUBLISH
On 27 February 2017 at 10:12, Amit Langote
wrote:
> I agree that my patch failed to de-emphasize the old partitioning method
> enough. The examples in 5.11 Partitioning chapter also did not highlight
> the new partitioning feature as much as it should have been, so it indeed
> reads like a descr
On 2017/02/15 12:00, Robert Haas wrote:
> On Fri, Feb 10, 2017 at 3:00 AM, Simon Riggs wrote:
>
>> Without claiming I'm happy about this, I think the best way to improve
>> the number of eyeballs on this is to commit these docs as is.
>>
>> For me, the most important thing is understanding the fe
On 2017/02/27 3:18, Petr Jelinek wrote:
> On 24/02/17 07:15, Robert Haas wrote:
>> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote:
>>> The good news is that logical replication DOES work with partitioning,
>>> but only for a Publication with PUBLISH INSERT, pushing from a normal
>>> table to a
On 24/02/17 07:15, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote:
>> The good news is that logical replication DOES work with partitioning,
>> but only for a Publication with PUBLISH INSERT, pushing from a normal
>> table to a partitioned one. Which is useful enough for f
On Sun, Feb 26, 2017 at 4:31 AM, Bruce Momjian wrote:
> I think you are right. I was only guessing on a possible cause of
> Simon's reaction since I had the same reaction. When traveling, it is
> hard to get excited about reading a 100+ post thread that has reached a
> conclusion. I found Simon
On Wed, Feb 22, 2017 at 07:44:41AM +0530, Robert Haas wrote:
> On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
> > I have to admit my reaction was similar to Simon's, meaning that the
> > lack of docs is a problem, and that the limitations are kind of a
> > surprise, and I wonder what other
On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote:
> The good news is that logical replication DOES work with partitioning,
> but only for a Publication with PUBLISH INSERT, pushing from a normal
> table to a partitioned one. Which is useful enough for first release.
>
> The work on having UPDATE
On 24 February 2017 at 02:36, Robert Haas wrote:
>> While its true that the patch had syntax documentation, there was no
>> user design documentation which explained how it worked to allow
>> objective review. Had I been able to provide input without reading
>> every email message, I would have d
On Fri, Feb 24, 2017 at 8:06 AM, Robert Haas wrote:
> Simon, this is ridiculous. We're 4 or 5 days away from the start of
> the last CommitFest. We have time to fix bugs and improve
> documentation and maybe tweak things here and there, but 3 and 4 are
> significant development projects. There
On 2/23/17 8:36 PM, Robert Haas wrote:
We're 4 or 5 days away from the start of
the last CommitFest. We have time to fix bugs and improve
documentation and maybe tweak things here and there, but 3 and 4 are
significant development projects. There isn't time to do that stuff
right now and get it
On Thu, Feb 23, 2017 at 10:00 PM, Simon Riggs wrote:
> You seem a little defensive about some reasonable review comments.
I am prone to that from time to time, and this may be an instance of it.
> While its true that the patch had syntax documentation, there was no
> user design documentation wh
On Thu, Feb 23, 2017 at 11:13 AM, Simon Riggs wrote:
> My argument was that CREATE INDEX is expected to just work on tables
> at present, so should also just work on partitioned tables. Without
> that, the reality is people will need to write scripts.
Really? What about postgres_fdw?
Even if tha
On 23 February 2017 at 17:27, Peter Geoghegan wrote:
> On Thu, Feb 23, 2017 at 8:08 AM, Simon Riggs wrote:
>> What claims are you talking about? Which things have been exaggerated,
>> and by whom?
>
> * The specious argument that we should "just" have CREATE INDEX create
> equivalent indexes acro
On 02/23/2017 09:27 AM, Peter Geoghegan wrote:
On Thu, Feb 23, 2017 at 8:08 AM, Simon Riggs wrote:
* "Good work so far, but there is still a very significant amount of
work to do."
There is always more work to do, so why say so? I think that the
implication is that this isn't complete as a f
On Thu, Feb 23, 2017 at 8:08 AM, Simon Riggs wrote:
> What claims are you talking about? Which things have been exaggerated,
> and by whom?
* The specious argument that we should "just" have CREATE INDEX create
equivalent indexes across partitions, to save all those people from
writing all those
On 22 February 2017 at 02:14, Robert Haas wrote:
> On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
>> I have to admit my reaction was similar to Simon's, meaning that the
>> lack of docs is a problem, and that the limitations are kind of a
>> surprise, and I wonder what other surprises ther
On 22 February 2017 at 19:57, Peter Geoghegan wrote:
> FWIW, I agree that some of what has been claimed about what
> contributors failed to do with this patch is exaggerated, and not in a
> way that I'd understand as hyperbole that drives home a deeper point.
What claims are you talking about? W
On Tue, Feb 21, 2017 at 6:14 PM, Robert Haas wrote:
> On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
>> I have to admit my reaction was similar to Simon's, meaning that the
>> lack of docs is a problem, and that the limitations are kind of a
>> surprise, and I wonder what other surprises t
On Tue, Feb 21, 2017 at 10:27 PM, Yugo Nagata wrote:
> There is a very small typo that a comma is missing.
> Attached is the patch to fix it.
Thank you. I have committed your patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-
On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
> I have to admit my reaction was similar to Simon's, meaning that the
> lack of docs is a problem, and that the limitations are kind of a
> surprise, and I wonder what other surprises there are.
Did you read my message upthread pointing out t
Hi,
There is a very small typo that a comma is missing.
Attached is the patch to fix it.
On Wed, 15 Feb 2017 07:57:53 -0500
Robert Haas wrote:
> On Wed, Feb 15, 2017 at 4:26 AM, Ashutosh Bapat
> wrote:
> > Noticed some typos in the documentation. Here's patch to correct
> > those. Sorry, if it
On Tue, Feb 21, 2017 at 9:57 AM, Amit Langote
wrote:
> On 2017/02/21 12:10, Ashutosh Bapat wrote:
>> I think, that's a limitation till we implement global indexes. But
>> nothing in the current implementation stops us from implementing it.
>> In fact, I remember, a reply from Robert to another thr
On 2017/02/21 12:10, Ashutosh Bapat wrote:
> I think, that's a limitation till we implement global indexes. But
> nothing in the current implementation stops us from implementing it.
> In fact, I remember, a reply from Robert to another thread on
> partitioning started in parallel to Amit's thread
On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
> On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote:
>> On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote:
>> > On 15 February 2017 at 15:46, Robert Haas wrote:
>> >>> It leaves me asking what else is missing.
>> >>
>> >> There is
On 2017/02/16 10:45, Amit Langote wrote:
> Also attaching 0002 (unchanged) for tab-completion support for the new
> partitioning syntax.
Robert already spawned a new thread titled "tab completion for
partitioning" for this [0].
> 0003 changes how ExecFindPartition() shows the row for which
> get_
On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote:
> > On 15 February 2017 at 15:46, Robert Haas wrote:
> >>> It leaves me asking what else is missing.
> >>
> >> There is certainly a lot of room for improvement here but I don't
> >>
On Wed, Feb 15, 2017 at 12:08:19PM -0500, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
> wrote:
> > I think new-style partitioning is supposed to consider each partition as
> > an implementation detail of the table; the fact that you can manipulate
> > partitions separatel
On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote:
> On 15 February 2017 at 15:46, Robert Haas wrote:
>>> It leaves me asking what else is missing.
>>
>> There is certainly a lot of room for improvement here but I don't
>> understand your persistent negativity about what's been done thus far.
>>
On 2017/02/20 1:04, Robert Haas wrote:
> On Thu, Feb 16, 2017 at 12:43 PM, Amit Langote wrote:
>> So I count more than a few votes saying that we should be able to DROP
>> partitioned tables without specifying CASCADE.
>>
>> I tried to implement that using the attached patch by having
>> StoreCatal
On 15 February 2017 at 15:46, Robert Haas wrote:
>> It leaves me asking what else is missing.
>
> There is certainly a lot of room for improvement here but I don't
> understand your persistent negativity about what's been done thus far.
> I think it's pretty clearly a huge step forward, and I thi
On Thu, Feb 16, 2017 at 12:43 PM, Amit Langote
wrote:
> On 2017/02/16 2:08, Robert Haas wrote:
>> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
>> wrote:
>>> I think new-style partitioning is supposed to consider each partition as
>>> an implementation detail of the table; the fact that you ca
On Thu, Feb 16, 2017 at 7:15 AM, Amit Langote
wrote:
>> I think 0001 is better than the status quo, but I'm wondering whether
>> we should try to do something slightly different. Maybe it should
>> always work for the child table to specify neither WITH OIDS nor
>> WITHOUT OIDS, but if you do spe
On Fri, Feb 17, 2017 at 11:25 AM, Ashutosh Bapat
wrote:
> Forgot to attach the patch. Thanks Rajkumar for notifying me.
I think this is overexplaining what is anyway obvious.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
Forgot to attach the patch. Thanks Rajkumar for notifying me.
On Fri, Feb 17, 2017 at 11:18 AM, Ashutosh Bapat
wrote:
> In the documentation of ALTER TABLE ... ATTACH PARTITION its implicit
> that partition name specified should be the name of the existing table
> being attached. Same is the case
In the documentation of ALTER TABLE ... ATTACH PARTITION its implicit
that partition name specified should be the name of the existing table
being attached. Same is the case with DETACH PARTITION where its
implicit that the detached partition becomes a stand-alone table with
same name as the partit
On 2017/02/16 2:08, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
> wrote:
>> I think new-style partitioning is supposed to consider each partition as
>> an implementation detail of the table; the fact that you can manipulate
>> partitions separately does not really mean th
On 2017/02/15 13:31, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote
> wrote:
>> On 2017/02/13 14:21, Amit Langote wrote:
>>> On 2017/02/10 19:19, Simon Riggs wrote:
* The OID inheritance needs work - you shouldn't need to specify a
partition needs OIDS if the parent h
Alvaro Herrera writes:
> Robert Haas wrote:
>> True. I think the question here is: do we want to view the dependency
>> between a partitioned table and a partition of that table as
>> DEPENDENCY_NORMAL or as DEPENDENCY_AUTO? With table inheritance, it's
>> always been "normal" and I'm not sure t
On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
wrote:
> I think new-style partitioning is supposed to consider each partition as
> an implementation detail of the table; the fact that you can manipulate
> partitions separately does not really mean that they are their own
> independent object. Y
Robert Haas wrote:
> On Wed, Feb 15, 2017 at 9:37 AM, Alvaro Herrera
> wrote:
> > Joshua D. Drake wrote:
> >> Because partitions may have data.
> >
> > So would the table, were it not partitioned.
>
> True. I think the question here is: do we want to view the dependency
> between a partitioned
On Wed, Feb 15, 2017 at 9:10 AM, Simon Riggs wrote:
>>> * "ERROR: cannot create index on partitioned table
>>> "measurement_year_month""
>>> is misleading because you can create indexes on partitions
>>
>> Do you mean that this should not cause an error at all, but create the
>> specified index
On Wed, Feb 15, 2017 at 9:37 AM, Alvaro Herrera
wrote:
> Joshua D. Drake wrote:
>> On 02/15/2017 06:10 AM, Simon Riggs wrote:
>> > On 13 February 2017 at 05:21, Amit Langote
>> > wrote:
>>
>> > If I issue DROP TABLE elsewhere, it doesn't refuse to drop because it
>> > has indexes, sequences etc o
Joshua D. Drake wrote:
> On 02/15/2017 06:10 AM, Simon Riggs wrote:
> > On 13 February 2017 at 05:21, Amit Langote
> > wrote:
>
> > If I issue DROP TABLE elsewhere, it doesn't refuse to drop because it
> > has indexes, sequences etc on it. So why should it just because it has
> > partitions?
>
>
On 02/15/2017 06:10 AM, Simon Riggs wrote:
On 13 February 2017 at 05:21, Amit Langote
wrote:
If I issue DROP TABLE elsewhere, it doesn't refuse to drop because it
has indexes, sequences etc on it. So why should it just because it has
partitions?
Because partitions may have data.
JD
--
C
On 13 February 2017 at 05:21, Amit Langote
wrote:
>> Few points from tests
>>
>> * "ERROR: cannot create index on partitioned table "measurement_year_month""
>> is misleading because you can create indexes on partitions
>
> Do you mean that this should not cause an error at all, but create the
>
On Wed, Feb 15, 2017 at 4:26 AM, Ashutosh Bapat
wrote:
> Noticed some typos in the documentation. Here's patch to correct
> those. Sorry, if it has been already taken care of.
Thanks. That is indeed nonstandard capitalization. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.co
Noticed some typos in the documentation. Here's patch to correct
those. Sorry, if it has been already taken care of.
On Wed, Feb 15, 2017 at 10:01 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote
> wrote:
>> On 2017/02/13 14:21, Amit Langote wrote:
>>> On 2017/02/10 19:19,
On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote
wrote:
> On 2017/02/13 14:21, Amit Langote wrote:
>> On 2017/02/10 19:19, Simon Riggs wrote:
>>> * The OID inheritance needs work - you shouldn't need to specify a
>>> partition needs OIDS if the parent has it already.
>>
>> That sounds right. It's be
On Fri, Feb 10, 2017 at 3:00 AM, Simon Riggs wrote:
> Given that we already have partitioning feature committed, we really
> need to have the docs committed as well.
Just for the record, it's not like there were no documentation changes
in the originally committed patch. In fact there were over
On 2017/02/13 14:21, Amit Langote wrote:
> On 2017/02/10 19:19, Simon Riggs wrote:
>> On 10 February 2017 at 08:18, Amit Langote
>> wrote:
>>
>>> I agree that getting the proposed documentation changes committed would be
>>> a step ahead.
>>
>> Committed. I tested how it works and added documentat
On 2017/02/13 14:21, Amit Langote wrote:
> On 2017/02/10 19:19, Simon Riggs wrote:
>> * The OID inheritance needs work - you shouldn't need to specify a
>> partition needs OIDS if the parent has it already.
>
> That sounds right. It's better to keep the behavior same as for regular
> inheritance.
On 2017/02/10 19:19, Simon Riggs wrote:
> On 10 February 2017 at 08:18, Amit Langote
> wrote:
>
>> I agree that getting the proposed documentation changes committed would be
>> a step ahead.
>
> Committed. I tested how it works and added documentation that matched
> my experiences, correcting wh
On 10 February 2017 at 08:18, Amit Langote
wrote:
> I agree that getting the proposed documentation changes committed would be
> a step ahead.
Committed. I tested how it works and added documentation that matched
my experiences, correcting what you'd said and adding more information
for clarity
On 2017/02/10 17:00, Simon Riggs wrote:
> On 10 February 2017 at 07:35, Amit Langote
> wrote:
>
>>> A final note, because I'm really familiar with partitioning on Postgres and
>>> other databases, documentation which is clear to me might not be to someone
>>> less familiar with partitioning. Mayb
On 10 February 2017 at 07:35, Amit Langote
wrote:
>> A final note, because I'm really familiar with partitioning on Postgres and
>> other databases, documentation which is clear to me might not be to someone
>> less familiar with partitioning. Maybe we want another reviewer for that?
>
> More eye
Hi Corey,
On 2017/02/09 6:14, Corey Huinker wrote:
> On Fri, Feb 3, 2017 at 4:15 AM, Amit Langote
> wrote:
>
>> Here are some patches to improve the documentation about partitioned
>> tables:
>
> Patch applies.
>
> Overall this looks really good. It goes a long way towards stating some of
> the
On Fri, Feb 3, 2017 at 4:15 AM, Amit Langote
wrote:
> Here are some patches to improve the documentation about partitioned
> tables:
>
> 0001: Adds some details about partition_bound_spec to the CREATE TABLE
> page, especially:
>
> - a note about inclusivity of range partition bounds,
> - a not
70 matches
Mail list logo
