Re: 2018-03 Commitfest Summary (Andres #3)

Hi Andres. On 2018/03/02 13:34, Andres Freund wrote: > - reorganize partitioning code > > NR. Created recently, but split off an older patch. > > Seems like a generally reasonable idea. Wonder if it conflicts with > some other partition related patches? It actually does. There are at

Re: Boolean partitions syntax

On 2018/03/02 15:58, Andres Freund wrote: > On 2018-02-02 17:00:24 -0500, Tom Lane wrote: >> Peter Eisentraut writes: >>> There might be other options, but one way to solve this would be to >>> treat partition bounds as a general expression in the grammar and

Re: Boolean partitions syntax

Horiguchi-san, On 2018/02/05 18:17, Kyotaro HORIGUCHI wrote: > At Mon, 29 Jan 2018 13:21:54 +0900, Amit Langote wrote: >> Partition bound literals as captured gram.y don't have any type >> information attached. They're carried over in a A_Const to >> transformPartitionBou

Re: pg_dump outputs invalid syntax for partitions with bool partkeys in pg10

Hi David. On 2018/03/02 12:41, David Rowley wrote: > Quite simply: > > d1=# create table bp (b bool) partition by list(b); > CREATE TABLE > d1=# create table bp_f partition of bp for values in('f'); > CREATE TABLE > d1=# \q > $ createdb d2 > $ pg_dump d1 | psql d2 > > ... > > ERROR: syntax

Re: [HACKERS] path toward faster partition pruning

On 2018/03/01 21:56, Robert Haas wrote: > On Tue, Feb 27, 2018 at 4:33 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Attached an updated version in which I incorporated some of the revisions >> that David Rowley suggested to OR clauses handling (in partpr

Re: [HACKERS] path toward faster partition pruning

Thanks for your comments. On 2018/03/02 4:13, Robert Haas wrote: > On Wed, Feb 28, 2018 at 11:53 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Attached updated patches. > > + memcpy(part_scheme->partsupfunc, partkey->partsupfunc, > +

Re: [HACKERS] path toward faster partition pruning

On 2018/03/02 11:12, David Rowley wrote: > On 2 March 2018 at 08:13, Robert Haas wrote: >> I don't like the comments at the top of partprune.c very much. It >> seems strange to document individual functions here; those functions >> can (and should) be documented in their

Re: [HACKERS] path toward faster partition pruning

On 2018/02/28 1:05, Robert Haas wrote: > On Mon, Feb 26, 2018 at 10:59 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> You may say that partition bounds might have to be different too in this >> case and hence partition-wise join won't occur a

Re: inserts into partitioned table may cause crash

Fujita-san, Thanks for the review. On 2018/03/05 22:00, Etsuro Fujita wrote: > I started reviewing this.  I think the analysis you mentioned upthread > would be correct, but I'm not sure the patch is the right way to go > because I think that exception handling added by the patch throughout >

Re: constraint exclusion and nulls in IN (..) clause

Hi. Thanks for reviewing again. On 2018/03/05 23:04, Emre Hasegeli wrote: >>> Shouldn't we check if we consumed all elements (state->next_elem >= >>> state->num_elems) inside the while loop? >> >> You're right. Fixed. > > I don't think the fix is correct. arrayconst_next_fn() can still >

Re: constraint exclusion and nulls in IN (..) clause

On 2018/03/06 19:16, Emre Hasegeli wrote: >> Hmm, state->next refers to two different pointer values on line 1 and line >> 2. It may end up being set to NULL on line 1. Am I missing something? > > True, lnext(state->next) can set it to NULL. I confused by the below > code on the same function

Re: minor fix for acquire_inherited_sample_rows

On Thu, Apr 26, 2018 at 9:54 PM, Ashutosh Bapat wrote: > On Thu, Apr 26, 2018 at 1:08 AM, Robert Haas wrote: >> +1. I think we're really abusing equalTupleDescs() for purposes for >> which it was not invented. Instead of changing it,

Re: partitioning - changing a slot's descriptor is expensive

On 2018/06/29 15:23, Amit Langote wrote: > Instead of a single TupleTableSlot attached at partition_tuple_slot, we > allocate an array of TupleTableSlot pointers of same length as the number > of partitions, as you mentioned upthread. We then call > MakeTupleTableSlot() only if a par

Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)

On 2018/06/29 6:23, Peter Eisentraut wrote: > On 6/28/18 22:52, Alvaro Herrera wrote: >>> Couldn't psql chase the pg_depend links to find inherited triggers? >> >> Yeah, I thought this would be exceedingly ugly, but apparently it's not >> *that* bad -- see the attached patch, which relies on the

Re: partition tree inspection functions

On 2018/06/28 22:01, Ashutosh Bapat wrote: > On Thu, Jun 28, 2018 at 11:19 AM, Amit Langote > wrote: >>> >>> It would have imagined that just creating a new file, say >>> partition_desc.sql or similar is nicer. >> >> How about partition_info.sql becaus

bug with expression index on partition

Hi. I noticed a bug with creating an expression index on a partitioned table. The fact that a partition may have differing attribute numbers is not accounted for when recursively *creating* the index on partition. The partition index gets created but is unusable. create table p (a int)

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On 2018/06/27 22:21, Ashutosh Bapat wrote: > On Wed, Jun 27, 2018 at 12:28 PM, Amit Langote >> Ah, okay. I thought of reporting this because I felt the errors may have >> to do with changes to the related code in HEAD between May 14 when you >> last posted the patches and to

Re: partition tree inspection functions

Thanks again for quick review. On 2018/06/28 12:43, Michael Paquier wrote: > On Thu, Jun 28, 2018 at 11:50:13AM +0900, Amit Langote wrote: >> For now, I've added them to create_table.sql, but maybe that's not where >> they really belong. Attached updated patch with tests. >

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/28 7:58, Alvaro Herrera wrote: > On 2018-Jun-18, Robert Treat wrote: >> So +1 for thinking we do need to worry about it. I'm not exactly sure >> how we want to expose that info; with \d+ we list various "Partition >> X:" sections, perhaps adding one for "Partition triggers:" would be >>

Re: partition tree inspection functions

Thanks for taking a look. On 2018/06/27 21:16, Michael Paquier wrote: > I would like to make things more user-friendly in this area, but could > you add a couple of tests to show up how things work? I just had a very > quick glance at what's proposed at the top of the thread. I thought about

Re: Postgres 11 release notes

On 2018/09/27 23:24, Alvaro Herrera wrote: > On 2018-Sep-27, Amit Langote wrote: > >> Sorry I couldn't reply sooner, but the following of your proposed text >> needs to be updated a bit: >> >> + >> + >> + Having a "default&

Re: Calculate total_table_pages after set_base_rel_sizes()

On Sat, Oct 13, 2018 at 7:36 David Rowley wrote: > On 12 October 2018 at 23:35, Amit Langote > wrote: > > On 2018/10/11 13:45, Amit Langote wrote: > >> On 2018/10/07 17:43, David Rowley wrote: > >>> Amit Langote has since posted a patch to delay the RangeTb

Re: speeding up planning with partitions

Hi David, I've managed to get back to the rest of your comments. Sorry that it took me a while. On 2018/09/11 8:23, David Rowley wrote: > On 30 August 2018 at 21:29, Amit Langote > wrote: >> Attached updated patches, with 0002 containing the changes mentioned above. > > He

Re: Speeding up INSERTs and UPDATEs to partitioned tables

Hi, On 2018/10/15 19:04, Krzysztof Nienartowicz wrote: > > We see quite prohibitive 5-6x slowdown with native partitioning on in > comparison to trigger based in PG9.5. > This is clearly visible with highly parallel inserts (Can share > flamediagrams comparing the two). > > This basically

Re: speeding up planning with partitions

Hi Dilip, Thanks for your review comments. Sorry it took me a while replying to them. On 2018/09/29 22:30, Dilip Kumar wrote: > I was going through your patch (v3-0002) and I have some suggestions > > 1. > - if (nparts > 0) > + /* > + * For partitioned tables, we just allocate space for

Re: partition tree inspection functions

On 2018/10/10 13:01, Michael Paquier wrote: > On Wed, Oct 10, 2018 at 11:54:48AM +0900, Amit Langote wrote: >> I was partly wrong in saying that we wouldn't need any changes to support >> partitioned indexes here. Actually, the core function >> find_inheritance_children woul

relhassubclass and partitioned indexes

Hi, $subject came up in [1]. Should relhassubclass be set/reset for partitioned indexes? The only use case being sought here is to use find_inheritance_children() for getting an index's partitions, but it uses relhassublcass test to short-circuit scanning pg_inherits. That means it cannot be

Re: Side effect of CVE-2017-7484 fix?

Hi, On 2018/10/22 14:41, Stephen Frost wrote: > Greetings, > > * Dilip Kumar (dilipbal...@gmail.com) wrote: >> As part of the security fix >> (e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the >> users from accessing the statistics of the table if the user doesn't >> have

Re: relhassubclass and partitioned indexes

Hi, On 2018/10/22 11:09, Michael Paquier wrote: > On Fri, Oct 19, 2018 at 06:46:15PM +0900, Amit Langote wrote: >> Thanks. Attached a patch to set relhassubclass when an index partition is >> added to a partitioned index. > > Thanks, committed after adding a test

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Sat, Jul 14, 2018 at 11:29 PM Tom Lane wrote: > > Peter Eisentraut writes: > > ... For > > partitioning, we can rely on all the columns being inherited, but not > > for plain inheritance. > > Uh, what? Maybe he meant that partitioning doesn't allow locally defined columns in children, but

Re: relhassubclass and partitioned indexes

On 2018/10/23 0:45, Alvaro Herrera wrote: > On 2018-Oct-22, Amit Langote wrote: > >> Hi, >> >> On 2018/10/22 11:09, Michael Paquier wrote: >>> On Fri, Oct 19, 2018 at 06:46:15PM +0900, Amit Langote wrote: >>>> Thanks. Attached a patch to set relhass

Re: speeding up planning with partitions

Imai-san, Thank you for reviewing. On 2018/10/04 17:11, Imai, Yoshikazu wrote: > Hi, Amit! > > On Thu, Sept 13, 2018 at 10:29 PM, Amit Langote wrote: >> Attached is what I have at the moment. > > I also do the code review of the patch. > I could only see a v3-000

Re: Calculate total_table_pages after set_base_rel_sizes()

On 2018/10/11 13:45, Amit Langote wrote: > On 2018/10/07 17:43, David Rowley wrote: >> Amit Langote has since posted a patch to delay the RangeTblEntry >> creation until after pruning. His patch happens to also move the >> total_table_pages calculation, but I believe this cha

Re: BUG #15448: server process (PID 22656) was terminated by exception 0xC0000005

Hi, On Tue, Oct 23, 2018 at 8:46 PM Andrew Dunstan wrote: > On 10/22/2018 10:00 PM, Amit Langote wrote: > > After observing the test case in the provided log, I managed to reproduce > > it with the following: > > > > create table foo (a int primary key, b int);

Re: A small tweak to some comments for PartitionKeyData

On 2018/10/25 12:54, David Rowley wrote: > On 25 October 2018 at 16:46, Amit Langote > wrote: >> +* key, one >> for each zero-valued partattrs */ >> >> How about: for each zero-valued member of partatt

Re: A small tweak to some comments for PartitionKeyData

On 2018/10/25 12:43, David Rowley wrote: > While doing a bit of work on a partitioning patch I noticed that it's > not really that obvious that there's meant to be exactly 1 item in the > partexprs List for each zero-valued partattrs element. Some incorrect > code using these fields was the cause

Re: A small tweak to some comments for PartitionKeyData

On 2018/10/25 13:13, David Rowley wrote: > On 25 October 2018 at 17:05, Amit Langote > wrote: >> On 2018/10/25 12:54, David Rowley wrote: >>> On 25 October 2018 at 16:46, Amit Langote >>> wrote: >>>> +

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

Thank you for creating the patch. On 2018/10/28 20:35, Dilip Kumar wrote: > On Sat, Oct 27, 2018 at 10:07 AM Dilip Kumar wrote: >> On Fri, Oct 26, 2018 at 1:12 PM Amit Langote wrote: >>> On 2018/10/25 19:54, Dilip Kumar wrote: >>>> Basically, if the relation is R

Re: partition tree inspection functions

On 2018/10/29 12:59, Michael Paquier wrote: > On Fri, Oct 19, 2018 at 06:55:09PM +0900, Amit Langote wrote: >> Yeah, we could make it the responsibility of the callers of >> find_all_inheritors and find_inheritance_children to check relhassubclass >> as an optimization and

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/10/30 8:41, Krzysztof Nienartowicz wrote: > On Thu, Oct 25, 2018 at 5:58 PM Krzysztof Nienartowicz > wrote: >> On Tue, Oct 23, 2018 at 4:02 AM David Rowley >> wrote: >>> >>> I more meant that it might be 0002 that fixes the issue for you. I >>> just wanted to check if you'd tried 0001

Re: partition tree inspection functions

On 2018/10/30 10:33, Michael Paquier wrote: > Thanks for the new version and using better index names. I have > reviewed and committed the patch, with a couple of things tweaked: > - removal of the tests on the size, they don't seem useful as part of > showing partition information. > - no need

Re: ToDo: show size of partitioned table

Hi Mathias, Pavel, On 2018/08/17 12:26, Mathias Brossard wrote: > On Thu, Aug 16, 2018 at 12:46 AM Pavel Stehule >> >> This is question - maybe we can support older partitioning based on only >> inheritance - and the query can be more exact on PostgreSQL 10 and newer. >> >> Please, send any

Re: Should pg 11 use a lot more memory building an spgist index?

On 2018/10/30 4:48, Tom Lane wrote: > I was confused about why the memory leak in Bruno's example is so much > larger in HEAD than v11; spgbeginscan does allocate more stuff than > before, but only if numberOfOrderBys > 0, which surely doesn't apply for > the exclusion-check code path. Eventually

Re: Should pg 11 use a lot more memory building an spgist index?

On 2018/10/30 4:48, Tom Lane wrote: > I wrote: >> Alvaro Herrera writes: >>> How about modifying SysScanDescData to have a memory context member, >>> which is created by systable_beginscan and destroyed by endscan? > >> I think it would still have problems, in that it would affect in which >>

move PartitionBoundInfo creation code

Hi, Currently, the code that creates a PartitionBoundInfo struct from the PartitionBoundSpec nodes of constituent partitions read from the catalog is in RelationBuildPartitionDesc that's in partcache.c. I think that da6f3e45dd that moved around the partitioning code [1] really missed the

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On 2018/09/14 10:53, Amit Langote wrote: > On 2018/09/13 23:13, Tom Lane wrote: >> Amit Langote writes: >>> On 2018/09/13 1:14, Tom Lane wrote: >>>> That seems excessively restrictive. Anything that has storage (e.g. >>>> matviews) ought to be tr

Re: move PartitionBoundInfo creation code

On 2018/11/01 13:02, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 12:58:29PM +0900, Amit Langote wrote: >> Attached find a patch that does such refactoring, along with making some >> functions in partbounds.c that are not needed outside static. > > This looks like a

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/01 8:58, David Rowley wrote: > On 1 November 2018 at 06:45, Robert Haas wrote: >> On Wed, Aug 22, 2018 at 8:30 AM David Rowley >> wrote: >>> On 22 August 2018 at 19:08, Amit Langote >>> wrote: >>>> +#define PartitionT

Re: Hooks to Modify Execution Flow and Query Planner

Hi, On 2018/11/01 16:58, Vincent Mirian wrote: > Hi all, > > I would like to create a library with UDFs written in C that implements > different Query Planner tasks (e.g. scan, hash, join, etc...). I am looking > for a document that provides an overview of execution flow within postgres > and

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/01 10:30, David Rowley wrote: > It's great to know the patch is now so perfect that we've only the > macro naming left to debate ;-) I looked over v12 again and noticed a couple minor issues. + * table then we store the index into parenting + *

Re: Should pg 11 use a lot more memory building an spgist index?

On Tue, Oct 30, 2018 at 7:11 PM Amit Langote wrote: > > On 2018/10/30 4:48, Tom Lane wrote: > > I wrote: > >> Alvaro Herrera writes: > >>> How about modifying SysScanDescData to have a memory context member, > >>> which is created by systable_beginsc

Re: ToDo: show size of partitioned table

On Tue, Oct 30, 2018 at 8:04 PM Pavel Stehule wrote: > út 30. 10. 2018 v 7:52 odesílatel Amit Langote > napsal: >> The patch to add the pg_partition_tree() function was just committed: >> >> Add pg_partition_tree to display information about partitions >> https:

Re: ToDo: show size of partitioned table

On 2018/10/31 15:30, Pavel Stehule wrote: > st 31. 10. 2018 v 3:27 odesílatel Amit Langote < > langote_amit...@lab.ntt.co.jp> napsal: >> +appendPQExpBufferStr(, "\nWHERE c.relkind IN ('p')\n"); >> >> I wonder if we should list partitioned inde

Re: Should pg 11 use a lot more memory building an spgist index?

On 2018/10/30 21:27, Amit Langote wrote: > On Tue, Oct 30, 2018 at 7:11 PM Amit Langote >> I've tried to fix that with the attached patches. >> >> 0001 adds the ability for the callers of index_beginscan to specify a >> memory context. index_beginscan_internals swit

Re: FDW Parallel Append

Hi, On 2018/10/31 3:25, Sanyo Moura wrote: > Hi hackers, > > I am trying to improve my xdr_fdw (a foreign data wrapper that scan file > systems that keep big data compacted) to scan partitions in parallel. > > But when I execute or analyze I get an error: > > EXPLAIN ANALYZE SELECT * FROM

Re: ToDo: show size of partitioned table

On 2018/10/30 20:03, Pavel Stehule wrote: > út 30. 10. 2018 v 7:52 odesílatel Amit Langote < > langote_amit...@lab.ntt.co.jp> napsal: >> Could one of you please revise the patch to use that function to produce >> the output of \dP+? >> > > here it is. > >

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/04 19:07, David Rowley wrote: > On 1 November 2018 at 22:39, Amit Langote > wrote: > I've attached v13 which hopefully addresses these. Thank you for updating the patch. >> The macro naming discussion got me thinking today about the macro itself. >> I

Re: ToDo: show size of partitioned table

On 2018/11/04 4:58, Pavel Stehule wrote: > here is a patch Thank you, Pavel. Here are some comments. I mentioned it during the last review, but maybe you missed it due to the other discussion. +the pattern are listed. If the form \dP+ +is used, a sum of size of related

Re: ToDo: show size of partitioned table

Hi, On 2018/11/01 2:19, Pavel Stehule wrote: > st 31. 10. 2018 v 7:34 odesílatel Amit Langote < > langote_amit...@lab.ntt.co.jp> napsal: >> On 2018/10/31 15:30, Pavel Stehule wrote: >>> st 31. 10. 2018 v 3:27 odesílatel Amit Langote < >>>

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

Hi, On 2018/11/02 14:27, Michael Paquier wrote: > On Fri, Nov 02, 2018 at 02:18:04PM +0900, Michael Paquier wrote: >> This case is funky. Interesting indeed. >> The parent gets dropped at commit time, but it does >> not know that it should drop the child as well per their dependencies. >> This

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On 2018/11/01 20:34, Dilip Kumar wrote: > On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote: >> Anyway, why don't we just use the child table's AppendRelInfo to get the >> parent's version of varattno instead of creating a new function? It can >> be done as shown in the att

Re: partitioned indexes and tablespaces

Hi, On 2018/11/02 10:27, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 09:31:38PM -0300, Alvaro Herrera wrote: >> A customer reported to us that partitioned indexes are not working >> consistently with tablespaces: > > Let's see... > >> 1. When a CREATE INDEX specifies a tablespace, existing

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On 2018/11/02 10:51, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 01:04:43PM +0900, Michael Paquier wrote: >> On Thu, Nov 01, 2018 at 12:39:16PM +0900, Amit Langote wrote: >>> Rajkumar pointed out off-list that the patch still remains to be applied. >>> Consider

Re: Ordered Partitioned Table Scans

On 2018/10/26 11:50, David Rowley wrote: > RANGE partitioning of time-series data is quite a common range to use > partitioning, and such tables tend to grow fairly large. I thought > since we always store RANGE partitioned tables in the PartitionDesc in > ascending range order that it might be

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On 2018/10/25 19:54, Dilip Kumar wrote: > On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote: >> Amit Langote writes: >>> But maybe for the case under question, that's irrelevant, because >>> we're only interested in access to inherited columns as those are the >>

Re: Should pg 11 use a lot more memory building an spgist index?

On 2018/10/26 18:16, Tom Lane wrote: > The core of the problem I see is that check_exclusion_or_unique_constraint > does index_beginscan/index_rescan/index_endscan in a long-lived context, > while spgendscan seems to have employed dice while deciding which of > spgbeginscan's allocations it would

Re: Should pg 11 use a lot more memory building an spgist index?

On 2018/10/26 18:59, Tom Lane wrote: > Amit Langote writes: >> On 2018/10/26 18:16, Tom Lane wrote: >>> A quick review of the other index AM endscan methods seems to indicate >>> that they all try to clean up their mess. So maybe we should just make >>> spgend

Re: relhassubclass and partitioned indexes

Thanks for commenting. On 2018/10/19 15:17, Michael Paquier wrote: > On Fri, Oct 19, 2018 at 01:45:03AM -0400, Tom Lane wrote: >> Amit Langote writes: >>> Should relhassubclass be set/reset for partitioned indexes? >> >> Seems like a reasonable idea to me, at le

Re: partition tree inspection functions

On 2018/10/19 16:47, Michael Paquier wrote: > On Fri, Oct 19, 2018 at 01:05:52PM +0900, Amit Langote wrote: >> As I said above, the price of removing relhassubclass might be a bit >> steep. So, the other alternative I mentioned before is to set >> relhassubclass correctly eve

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

Hi, On 2018/11/07 0:10, Alvaro Herrera wrote: > Looking over the stuff in gram.y (to make sure there's nothing that > could be lost), I noticed that we're losing the COLLATE clause when they > are added to columns in partitions. I would expect part1 to end up with > collation es_CL, or

Re: First-draft release notes for back-branch releases

On 2018/11/07 11:28, Noah Misch wrote: > On Mon, Nov 05, 2018 at 10:49:30PM -0500, Jonathan S. Katz wrote: >> On 11/5/18 9:58 PM, Amit Langote wrote: >>> On 2018/11/06 11:25, Noah Misch wrote: >>>> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wr

Re: speeding up planning with partitions

Thanks for looking. On 2018/11/07 12:32, Alvaro Herrera wrote: > ISTM patch 0004 is impossible to review just because of size -- I > suppose the bulk of it is just code that moves from one file to another, > but that there are also code changes in it. Maybe it would be better to > split it so

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/07 20:46, David Rowley wrote: > On 5 November 2018 at 20:17, Amit Langote > wrote: >> On 2018/11/04 19:07, David Rowley wrote: >>> Perhaps a better design would be to instead of having random special >>> partitioned-table-only fields in ResultRelInfo,

Re: ATTACH/DETACH PARTITION CONCURRENTLY

of reducing lock levels, and we certainly couldn't > do it without having some efficient way to check whether it had > already been done. So then the mechanism wouldn't feel like so much > like a special-purpose hack just for concurrent ATTACH/DETACH. (Was > Amit Langote already working on this, or was that some other kind of > on-demand locking?) I think the patch mentioned above gets us closer to that goal. Thanks, Amit

Re: move PartitionBoundInfo creation code

On 2018/11/08 11:48, Michael Paquier wrote: >>> Thinking crazy, we could also create a subfolder partitioning/bounds/ >>> which includes three files with this refactoring:x >>> - range.c >>> - values.c >>> - hash.c >>> Then we keep partbounds.c which is the entry point used by partcache.c, >>> and

Re: ON COMMIT actions and inheritance

Hi, Thank you updating the patch and adding notes to the documentation about the points I raised. On 2018/11/07 9:53, Michael Paquier wrote: > On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote: >> Agree with keeping it simple. Maybe, we could (should?) document that th

Re: ON COMMIT actions and inheritance

On 2018/11/08 18:03, Michael Paquier wrote: > On Thu, Nov 08, 2018 at 04:46:46PM +0900, Amit Langote wrote: >> How about: >> When used on tables with inheritance children (including partitioned >> tables), this also drops the children (partitions). > > Even if the styl

Re: move PartitionBoundInfo creation code

On 2018/11/08 0:04, Alvaro Herrera wrote: >> On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote: >>> I think we can design the interface of partition_bounds_create such that >>> it returns information needed to re-arrange OIDs to be in the canonical >&

Re: move PartitionBoundInfo creation code

On 2018/11/08 12:59, Amit Langote wrote: > It might be okay to split the big switch in partition_bounds_create() into > different functions for different partitioning methods for clarity as you > say, but let's avoid creating new files for range, list, and hash. > > I will post a

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

On 2018/11/09 14:04, Amit Langote wrote: > On 2018/11/09 4:39, Alvaro Herrera wrote: >> and if somebody has it, a change to how defaults are applied >> when routing tuples. > > I haven't written such a patch yet. Do we want such a feature? Or is it a *bug* of tuple-ro

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

On 2018/11/09 1:38, Alvaro Herrera wrote: > On 2018-Nov-09, Amit Langote wrote: > >> On Fri, Nov 9, 2018 at 1:03 AM Alvaro Herrera >> wrote: >>> On 2018-Nov-07, Amit Langote wrote: > >>> Hmm, I'm thinking perhaps we shouldn't backpatch this part. It's

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

On 2018/11/09 4:39, Alvaro Herrera wrote: > Pushed. Thank you for committing. I've closed the CF entry. > I included the test case for collations to the three branches, but no > code changes. We can patch master for the handling of collations per > your patch, Okay, but should we back-patch

Re: move PartitionBoundInfo creation code

On 2018/11/13 11:34, Michael Paquier wrote: > Attached is an updated patch. Perhaps you are spotting something else? Looks good to me. Thanks, Amit

Re: move PartitionBoundInfo creation code

On 2018/11/13 12:40, Amit Langote wrote: > On 2018/11/13 11:34, Michael Paquier wrote: >> Attached is an updated patch. Perhaps you are spotting something else? > > Looks good to me. Marked the CF entry as Ready for Committer. Thanks, Amit

Re: move PartitionBoundInfo creation code

Hi, On 2018/11/12 22:55, Michael Paquier wrote: > On Thu, Nov 08, 2018 at 03:11:35PM +0900, Amit Langote wrote: >> And here is the new version. The break down into smaller local >> functions for different partitioning methods is in patch 0002. > > Okay, here we go. Th

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

On 2018/11/10 7:33, Tom Lane wrote: > Alvaro Herrera writes: >> On 2018-Nov-09, Jürgen Strobel wrote: >>> Regarding your example, what I expected is that *both* inserts would >>> consistently result in a tuple of (1, 42) since p should route the >>> insert to p1 and use p1's defaults. The current

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

On 2018/11/12 12:59, Tom Lane wrote: > Amit Langote writes: >> On 2018/11/10 7:33, Tom Lane wrote: >>> I'd argue not, actually. I think there is plausible precedent in >>> updatable views, where what we use is the defaults associated with the >>> view, not th

Re: move PartitionBoundInfo creation code

Hi, On 2018/11/13 22:59, Alvaro Herrera wrote: > On 2018-Nov-13, Michael Paquier wrote: > >> On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote: >>> "the context that was active when the function was called" is typically >>> expressed simply as "the current memory context". Perhaps

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/14 0:32, Jesper Pedersen wrote: > Hi, > > On 11/12/18 6:17 PM, David Rowley wrote: >> On 9 November 2018 at 19:18, Amit Langote >> wrote: >>> I have a comment regarding how you chose to make >>> PartitionTupleRouting private. >>> &g

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On 2018/11/15 22:57, Robert Haas wrote: > On Thu, Nov 15, 2018 at 12:38 AM Michael Paquier wrote: >> On Thu, Nov 15, 2018 at 01:38:55PM +0900, Amit Langote wrote: >>> I've fixed 0001 again to re-order the code so that allocations happen the >>> correct context and now

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Fri, Nov 16, 2018 at 1:00 PM Michael Paquier wrote: > On Fri, Nov 16, 2018 at 10:57:57AM +0900, Amit Langote wrote: > > Maybe partition_bounds_create() should've had a MemoryContext argument to > > pass it the context we want it to create the PartitionBoundInfo in. That > &g

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On Fri, Nov 16, 2018 at 11:40 AM Alvaro Herrera wrote: > On 2018-Nov-15, Amit Langote wrote: > > > Maybe name it PARTITION_INIT_ALLOCSIZE (dropping the ROUTING from it), or > > PROUTE_INIT_ALLOCSIZE, to make it clear that it's only allocation size? > > Here's a proposed

Re: move PartitionBoundInfo creation code

Hi, Thank your for taking a look. On 2018/11/05 16:21, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote: >> Done a few moments ago. :) > > From the file size this move is actually negative. From what I can see > partcache decreases t

Re: First-draft release notes for back-branch releases

Hi, On 2018/11/07 13:08, Jonathan S. Katz wrote: > Thanks. I left it as "Fix several crashes with triggers" - please see > attached. Thank you. Just one more comment on the top sentence. * Ensure that if a parent partition has an index created in a tablespace, then all child indexes will be

Re: First-draft release notes for back-branch releases

Hi, On 2018/11/06 12:49, Jonathan S. Katz wrote: > On 11/5/18 9:58 PM, Amit Langote wrote: >> On 2018/11/06 11:25, Noah Misch wrote: >>> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote: >>>> Attached is a draft of the press release

Re: First-draft release notes for back-branch releases

On 2018/11/06 11:25, Noah Misch wrote: > On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote: >> Attached is a draft of the press release for review. Please let me know >> if there are any corrections/suggestions. >> * Disallows the creation of a new partition from a trigger that is

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On 2018/11/06 4:37, Alvaro Herrera wrote: > On 2018-Nov-02, Amit Langote wrote: > >> Well, performDeletion *does* drop the child, because when the parent is >> dropped due to its ON COMMIT DROP action, it's done using: >> >> /* >>

Re: ON COMMIT actions and inheritance

Hi, On 2018/11/06 12:03, Michael Paquier wrote: > On Mon, Nov 05, 2018 at 02:37:05PM +0900, Amit Langote wrote: >> Michael pointed out a problem with specifying different ON COMMIT actions >> on a temporary inheritance parent and its children: >> >> https://ww

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

Hi, Thank you for looking at this. On 2018/11/06 7:25, Alvaro Herrera wrote: > On 2018-Aug-07, Amit Langote wrote: > >>> But in >>> case of partitioning there is only one parent and hence >>> coldef->constraints is NULL and hence just overwriting it

Re: Speeding up INSERTs and UPDATEs to partitioned tables

Thanks for updating the patch. On 2018/11/14 13:16, David Rowley wrote: > Thanks for looking at this again. > > On 14 November 2018 at 13:47, Amit Langote > wrote: >> +if (dispatchidx >= proute->dispatch_allocsize) >> +{ >> +/* Expand al

<    1   2   3   4   5   6   7   8   9   10   >