On Wed, Jul 31, 2019 at 2:38 AM Robert Haas wrote:
>
> On Tue, Jul 2, 2019 at 9:53 PM Amit Langote wrote:
> > Thanks for the report. This seems like a bug. Documentation claims
> > that the child tables inherit column storage options from the parent
> > table. That
On Wed, Jul 31, 2019 at 8:31 AM Tom Lane wrote:
> David Rowley writes:
> > On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
> >> The portion of this below the Append is fine, but I argue that
> >> the Vars above the Append should say "part", not "part_p1".
> >> In that way they'd look the same rega
On Tue, Jul 30, 2019 at 6:00 PM Etsuro Fujita wrote:
> On Fri, Jul 19, 2019 at 10:44 PM Robert Haas wrote:
> > On Thu, Jul 18, 2019 at 2:55 AM Etsuro Fujita
> > wrote:
> > > I.e., partition_bounds_merge() is performed for each pair of input
> > > partitioned relations for a join relation in try
On Tue, Jul 30, 2019 at 4:20 PM Amit Langote wrote:
> On Sat, Jul 20, 2019 at 1:52 AM Andres Freund wrote:
> > > The first one (0001) deals with reducing the core executor's reliance
> > > on es_result_relation_info to access the currently active result
> > >
Hello,
I noticed that the patch is still marked as "Waiting on Author" ever
since Shawn set it that way on June 17. Since Hosoya-san posted
updated patches on June 27, the status should've been changed to
"Needs Review". Or maybe "Ready for Committer", because the last time
I looked, at least th
Fujita-san,
Thanks for the reply and sorry I didn't wait a bit more before posting
the patch.
On Wed, Jul 31, 2019 at 9:04 PM Etsuro Fujita wrote:
> On Wed, Jul 31, 2019 at 5:05 PM Amit Langote wrote:
> > On Tue, Jul 30, 2019 at 4:20 PM Amit Langote
> > wrote:
> > &
On Wed, Jul 31, 2019 at 9:49 PM Alvaro Herrera wrote:
> On 2019-Jul-31, Amit Langote wrote:
> > I noticed that the patch is still marked as "Waiting on Author" ever
> > since Shawn set it that way on June 17. Since Hosoya-san posted
> > updated patches on Jun
On Fri, Aug 2, 2019 at 9:18 AM Thomas Munro wrote:
> On Thu, Aug 1, 2019 at 7:12 PM Pavlo Golub wrote:
> > > As a normal lurker on hackers, it has been nice seeing the weekly
> > > updates. Thanks for those.
> >
> > Yeap! Great job! Please, do the same for the rest of our lifes. :)
>
> I guess t
Hi Alvaro,
On Mon, Aug 5, 2019 at 12:24 AM Alvaro Herrera wrote:
>
> On 2019-Aug-04, Alvaro Herrera wrote:
>
> > So this is the best commit messages I could come up with at this stupid
> > hour. I think the wording is pretty poor but at least it seems correct.
> > I'm not sure I'll be able to ge
Hi,
On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita wrote:
> On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > > If those are the choices, adding a parameter is clearly the preferable
> > > solution, because it makes the API breakage obvious a
Fujita-san,
Thanks for the quick follow up.
On Mon, Aug 5, 2019 at 2:31 PM Etsuro Fujita wrote:
> On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> > On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita
> > wrote:
> > > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
Hi Andres, Fujita-san,
On Sat, Aug 3, 2019 at 3:01 AM Andres Freund wrote:
> On 2019-07-31 17:04:38 +0900, Amit Langote wrote:
> > I looked into trying to do the things I mentioned above and it seems
> > to me that revising BeginDirectModify()'s API to receive the
> >
Hi Alvaro,
On Mon, Aug 5, 2019 at 11:39 PM Alvaro Herrera wrote:
> On 2019-Aug-05, yuzuko wrote:
>
> > So I proposed moving the if() block to the current place.
> > The latest patch can solve both queries but I found the latter
> > problem can be solved by setting constraint_exclusion = on.
>
> S
Hi,
Attached patch for:
s/incompable/incompatible/g
Thanks,
Amit
add_partial_path-typo.patch
Description: Binary data
On Tue, Aug 6, 2019 at 6:12 PM Michael Paquier wrote:
>
> On Tue, Aug 06, 2019 at 05:34:06PM +0900, Amit Langote wrote:
> > Attached patch for:
> >
> > s/incompable/incompatible/g
>
> Thanks, applied.
Thank you Michael.
Regards,
Amit
Fujita-san,
Thanks a lot the review.
On Tue, Aug 6, 2019 at 9:56 PM Etsuro Fujita wrote:
> On Mon, Aug 5, 2019 at 6:16 PM Amit Langote wrote:
> > I first thought to set it
> > only if direct modification is being used, but maybe it'd be simpler
> > to set it even if
Hi Alvaro,
On Wed, Aug 7, 2019 at 7:27 AM Alvaro Herrera wrote:
>
> Given the discussion starting at
> https://postgr.es/m/cafjfprdbiqjzm8sg9+s0x8re-afhds6mflgguw0wvunlgrv...@mail.gmail.com
> we don't have default-partition support with the hash partitioning
> scheme. That seems a reasonable out
Hi,
On Wed, Aug 7, 2019 at 8:02 AM Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Alvaro Herrera writes:
> > > On 2019-Aug-06, Tom Lane wrote:
> > >> Seems like "it's likely to cause trouble for users" is just going to
> > >> beg the question "why?". Can we explain the hazard
Fujita-san,
Thanks for the quick follow up.
On Wed, Aug 7, 2019 at 11:30 AM Etsuro Fujita wrote:
> On Wed, Aug 7, 2019 at 10:24 AM Amit Langote wrote:
> > * Regarding setting ForeignScan.resultRelIndex even for non-direct
> > modifications, maybe that's not a good idea
On Wed, Aug 7, 2019 at 7:47 AM Alvaro Herrera wrote:
>
> Hello, here's a pretty trivial cleanup.
>
> Currently, you have to pass the errmsg text to convert_tuples_by_name
> and convert_tuples_by_position that's going to be raised if the tuple
> descriptors don't match. In the latter's case that m
Horiguchi-san,
On Wed, Aug 7, 2019 at 1:59 PM Kyotaro Horiguchi
wrote:
> At Tue, 6 Aug 2019 23:26:19 -0400, Robert Haas wrote:
> > On Tue, Aug 6, 2019 at 6:58 PM Tom Lane wrote:
> > I think, as Amit says, that having an automatic partition creation
> > feature for hash partitions (and maybe oth
Hello,
On Wed, Aug 7, 2019 at 3:05 PM Danylo Hlynskyi wrote:
>
> The pool_passwd option [1] is specified relative to config file. But for
> greater flexibility absolute path should be accepted as well.
>
> If pool_passwd option starts with /, let's treat it as absolute path.
> Otherwise, it is
On Wed, Aug 7, 2019 at 3:30 PM yuzuko wrote:
> > In short, I propose to get this done as the patch I posted in
> > https://postgr.es/m/20190806133053.GA23706@alvherre.pgsql
> >
> I agree with your proposal. Also, I confirmed a default partition was pruned
> as expected with your patch.
+1.
Than
On Wed, Aug 7, 2019 at 12:00 PM Etsuro Fujita wrote:
> IIUC, I think we reached a consensus at least on the 0001 patch.
> Andres, would you mind if I commit that patch?
I just noticed obsolete references to es_result_relation_info that
0002 failed to remove. One of them is in fdwhandler.sgml:
Hi Konstantin,
On Wed, Aug 7, 2019 at 4:24 PM Konstantin Knizhnik
wrote:
>
> Hi hackers,
>
> I wonder if there is some particular reason for not handling
> T_RestrictInfo node tag in expression_tree_walker?
> There are many data structure in Postgres which contains lists of
> RestrictInfo or expr
Hi,
On Wed, Aug 7, 2019 at 5:07 PM Konstantin Knizhnik
wrote:
> On 07.08.2019 10:42, Amit Langote wrote:
> > You may also want to read this discussion:
> >
> > https://www.postgresql.org/message-id/553FC9BC.5060402%402ndquadrant.com
> >
> Thank you very much for re
On Thu, Aug 8, 2019 at 6:22 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Aug-07, Tom Lane wrote:
> >> Hm, that's rather confusingly worded IMO. Is the antecedent of "this
> >> option" just DEFAULT, or does it mean that you can't use FOR VALUES,
> >> or perchance it means that you can'
Fujita-san,
On Wed, Aug 7, 2019 at 6:00 PM Etsuro Fujita wrote:
> On Wed, Aug 7, 2019 at 4:28 PM Amit Langote wrote:
> > I just noticed obsolete references to es_result_relation_info that
> > 0002 failed to remove. One of them is in fdwhandler.sgml:
> >
&g
Hi Alvaro,
On Thu, Aug 8, 2019 at 5:27 AM Alvaro Herrera wrote:
> On 2019-Aug-07, Simon Riggs wrote:
> > I saw your recent commit and it scares me in various places, noted below.
> >
> > "Commit: Apply constraint exclusion more generally in partitioning"
> >
> > "This applies particularly to the
Hi Amul,
On Thu, Aug 8, 2019 at 4:15 PM amul sul wrote:
>
> Hi,
>
> In RelationBuildPartitionDesc(), a memory space that use to gather
> partitioning
> bound info wasn't free at the end. This might not a problem because this
> allocated memory will eventually be recovered when the top-level con
Hi Simon,
On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote:
> On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera wrote:
>> Well, yes, avoiding that is the point of this commit also: we were
>> scanning some partitions for some queries, after this patch we're
>> supposed not to.
>
>
> Understood
>
> My
On Thu, Aug 8, 2019 at 5:33 PM amul sul wrote:
> On Thu, Aug 8, 2019 at 1:27 PM Amit Langote wrote:
>> Thanks for the patch. This was discussed recently in the "hyrax vs.
>> RelationBuildPartitionDesc()" thread [1] and I think Alvaro proposed
>> an approach tha
Fujita-san,
On Thu, Aug 8, 2019 at 9:49 PM Etsuro Fujita wrote:
> On Thu, Aug 8, 2019 at 10:10 AM Amit Langote wrote:
> > Attached updated patches; only 0001 changed in this version.
>
> Thanks for the updated version, Amit-san! I updated the 0001 patch a
> bit further:
>
Horiguchi-san,
Thanks for the review.
On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
wrote:
> At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > When working on it, I realized
> > that the way RelOptInfo.partition_qual is processed is a bit
> > duplicative, so
On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote:
> On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> wrote:
> > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > > When working on it, I realized
> > > that the way RelOptInfo.partition_qual is processed
Thanks for the comments.
On Fri, Aug 9, 2019 at 2:44 PM Kyotaro Horiguchi
wrote:
> +++ b/src/backend/optimizer/util/plancat.c
> @@ -1267,10 +1267,14 @@ get_relation_constraints(PlannerInfo *root,
> */
>if (include_partition && relation->rd_rel->relispartition)
>{
> ...
> +else
>
Hi Alvaro,
On Tue, Aug 13, 2019 at 2:45 AM Alvaro Herrera wrote:
> v3-0001 still seems to leave things a bit duplicative. I think we can
> make it better if we move the logic to set RelOptInfo->partition_qual to
> a separate routine (set_baserel_partition_constraint mirroring the
> existing set_
On Wed, Aug 14, 2019 at 12:25 AM Alvaro Herrera
wrote:
> On 2019-Aug-13, Amit Langote wrote:
>
> > Thanks a lot for revising. Looks neat, except:
> >
> > + * This is a measure of last resort only to be used because the default
> > + * partition cannot be p
Hi Richard,
On Mon, Aug 26, 2019 at 6:33 PM Richard Guo wrote:
>
> Hi All,
>
> To generate partitionwise join, we need to make sure there exists an
> equi-join condition for each pair of partition keys, which is performed
> by have_partkey_equi_join(). This makes sense and works well.
>
> But if,
On Mon, Sep 2, 2019 at 6:31 AM Tom Lane wrote:
> I wrote:
> > As far as 4) goes, I think the code in ExtractReplicaIdentity is pretty
> > duff anyway, because it doesn't bother to check for the defined failure
> > return for RelationIdGetRelation. But if we're concerned about the
> > cost of reca
On 2018/01/05 1:28, Alvaro Herrera wrote:
>> From 8d627b910278203151853d324c3319c265cd36c0 Mon Sep 17 00:00:00 2001
>> From: amit
>> Date: Tue, 22 Aug 2017 13:48:13 +0900
>> Subject: [PATCH 2/5] Introduce a get_partitions_from_clauses()
>
> This one fails to apply. Please rebase.
Sorry about th
On 2018/01/04 23:29, Ashutosh Bapat wrote:
> On Fri, Dec 29, 2017 at 6:32 PM, Alvaro Herrera
> wrote:
>> I happened to notice that Ashutosh's patch series at
>> https://www.postgresql.org/message-id/CAFjFpReJhFSoy6DqH0ipFSHd=sLNEkSzAtz4VWCaS-w2jZL=u...@mail.gmail.com
>> has a 0001 patch that modi
David,
On 2018/01/12 12:30, David Rowley wrote:
> Can you also perform a self-review of the patch? Some of the things
> I'm picking up are leftovers from a previous version of the patch. We
> might never get through this review if you keep leaving those around!
Sorry, I will look more closely bef
Hi.
On 2018/01/12 18:09, David Rowley wrote:
> On 10 January 2018 at 17:18, David Rowley
> wrote:
>> Basically, the changes to add_paths_to_append_rel() are causing
>> duplication in partition_rels.
[ ... ]
> I also noticed earlier that this is still broken in v19.
I cannot see the duplicatio
On 2018/01/15 11:28, Stephen Frost wrote:
> Fujita-san, Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2017/06/21 16:59, Etsuro Fujita wrote:
>>> Commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50 added this to
>>> ExecInitModifyTable:
>>
Hi.
I used to think that $subject didn't happen, but it actually does and ends
up consuming a fixed 8192 bytes on the disk.
create table p (a int[]) partition by list (a);
CREATE TABLE
select pg_table_size('p');
pg_table_size
---
8192
(1 row)
select pg_relation_size(c1.o
On Wed, Jan 17, 2018 at 5:32 AM, Robert Haas wrote:
> On Tue, Jan 16, 2018 at 5:13 AM, Amit Langote
> wrote:
>> I used to think that $subject didn't happen, but it actually does and ends
>> up consuming a fixed 8192 bytes on the disk.
>>
>> create tab
On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier
wrote:
> On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
>> Yeah, pg_upgrade already has to cope with cases where the newer version
>> thinks a table needs a toast table when the older version didn't, or
>> vice versa. This looks like it
Hi David.
On Wed, Jan 17, 2018 at 12:32 PM, David Rowley
wrote:
> On 16 January 2018 at 21:08, Amit Langote
> wrote:
>> On 2018/01/12 12:30, David Rowley wrote:
>>> 8. The code in get_partitions_from_ne_clauses() does perform quite a
>>> few nested loops. I think
Hi David.
On Wed, Jan 17, 2018 at 6:19 PM, David Rowley
wrote:
> On 17 January 2018 at 17:05, David Rowley
> wrote:
>> 6. Which brings me to; why do we need match_clauses_to_partkey at all?
>> classify_partition_bounding_keys seems to do all the work
>> match_clauses_to_partkey does, plus more.
On 2018/01/17 22:51, Peter Eisentraut wrote:
> I'm setting this patch to Returned with feedback.
OK. Sorry that I couldn't reply here since the CF started. I have
written some code to implement the pg_partition_root() idea you mentioned
upthread earlier this week, but hasn't been able to share i
On 2018/01/02 22:45, Peter Eisentraut wrote:
> On 12/28/17 16:24, David Rowley wrote:
>>> select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid)
>>> from pg_class c
>>> order by 1
>>>
>>> select pg_partition_root(c.oid), sum(pg_table_size(c.oid))
>>> from pg_class c
>>> group by 1
Thank you Horiguchi-san!
On 2018/01/19 12:00, Kyotaro HORIGUCHI wrote:
> At Thu, 18 Jan 2018 11:41:00 -0800, Andres Freund wrote:
>> Hi Amit,
>>
>> It seems your mail system continually adds "[Sender Address Forgery]"
>> prefixes to messages. E.g. this mail now has
>> Subject: Re: [Sender Address
On 2017/12/19 19:06, Amit Langote wrote:
> Hi.
>
> I have a patch that rearranges the code around partition tuple-routing,
> such that allocation of per-partition objects (ResultRelInfo,
> TupleConversionMap, etc.) is delayed until a given partition is actually
> inserted into
Thanks for taking a look.
On 2018/01/19 14:39, Michael Paquier wrote:
> On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote:
>> I think having pg_partition_root() and pg_partition_parent() will give
>> users enough to get useful views as follows:
>
> So... pg_parti
On 2018/01/19 18:50, Amit Khandekar wrote:
> FYI ...
>
> For the pending update-partition-key patch, we would again require the
> rel variable for UPDATE. So in the rebased update-partition-key patch
> [1], 'rel' is assigned the root partitioned table. But this time, I
> have used the already open
On 2018/01/23 8:57, Thomas Munro wrote:
> On Tue, Jan 23, 2018 at 12:41 PM, Thomas Munro
> wrote:
>> On Mon, Jan 15, 2018 at 2:32 PM, Stephen Frost wrote:
>>> If someone else would like to review it, that'd be great, otherwise I'll
>>> probably get it committed soon.
>>
>> FYI the v2 doesn't buil
On 2018/01/23 14:35, Ashutosh Sharma wrote:
> I have created a regular table with CHECK constraint on the partition
> key column and it conflicts with the partition constraint but, still,
> i could attach the table with the partitioned table. Here is what i am
> trying to do,
>
> postgres[76308]=#
On 2018/01/23 15:55, Ashutosh Sharma wrote:
>> However, we don't make it fail because the table has a constraint that
>> contradicts the partition constraint. Attach succeeds in the absence of
>> any violating rows and the end result is that the table/partition has
>> contradictory constraints (th
Hi David.
On 2018/01/23 15:44, David Rowley wrote:
> On 19 January 2018 at 04:03, David Rowley
> wrote:
>> On 18 January 2018 at 23:56, Amit Langote
>> wrote:
>>> So, I've been assuming that the planner changes in the run-time pruning
>>> patch have
On 2018/01/23 20:43, Etsuro Fujita wrote:
> Here is a comment for get_qual_for_list in partition.c:
>
> * get_qual_for_list
> *
> * Returns an implicit-AND list of expressions to use as a list partition's
> - * constraint, given the partition key and bound structures.
>
> I don't think the
On 2018/01/20 7:07, Robert Haas wrote:
> On Fri, Jan 19, 2018 at 3:56 AM, Amit Langote
> wrote:
>> I rebased the patches, since they started conflicting with a recently
>> committed patch [1].
>
> I think that my latest commit has managed to break this pretty thoroughly.
On 2018/01/24 17:25, Amit Langote wrote:
> On 2018/01/20 7:07, Robert Haas wrote:
>> On Fri, Jan 19, 2018 at 3:56 AM, Amit Langote wrote:
>>> I rebased the patches, since they started conflicting with a recently
>>> committed patch [1].
>>
>> I think that my
Fujita-san,
Thanks for the review.
On 2018/01/23 20:13, Etsuro Fujita wrote:
> (2017/12/13 16:38), Amit Langote wrote:
>> Attached patch is an attempt at that. With the patch, instead of
>> internally generating an ANY/ALL expression, generate an OR expression
>> inste
Fujita-san,
Thanks for the review.
On 2018/01/25 18:30, Etsuro Fujita wrote:
> (2018/01/25 11:11), Amit Langote wrote:
>> Rebased again.
>
> Thanks for the rebased patch!
>
> The patches apply cleanly and compile successfully, but make check fails
> in an assert-enab
Fujita-san,
Thanks for the review.
On 2018/01/25 21:17, Etsuro Fujita wrote:
> Thanks for the updated patch! Some minor comments:
>
> + /*
> + * Construct an ArrayExpr for the non-null partition
> + * values
> + */
> +
Hi Stephen.
On 2018/01/26 10:16, Stephen Frost wrote:
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Still compiles and passes regression tests, which is good.
Thanks for looking at this.
>>> I extended your test a bit to check whether partitions over booleans
Hi.
I noticed that relispartition isn't set for index's partitions.
create table p (a int) partition by list (a);
create table p12 partition of p for values in (1, 2);
create index on p (a);
select relname, relkind from pg_class where relnamespace =
'public'::regnamespace and relispartition is tr
On 2018/01/22 11:44, Michael Paquier wrote:
> On Sun, Jan 21, 2018 at 07:16:38PM +1300, David Rowley wrote:
>> On 20 January 2018 at 23:14, Michael Paquier
>> wrote:
>>> If pg_partition_tree_tables() uses the top of the partition as input,
>>> all the tree should show up. If you use a leaf, anyth
Fujita-san,
On 2018/01/26 21:31, Etsuro Fujita wrote:
> (2018/01/26 10:15), Amit Langote wrote:
>> On 2018/01/25 21:17, Etsuro Fujita wrote:
>>> Some minor comments:
>>>
>>> + /*
>>> + * Cons
On 2018/01/27 3:32, Robert Haas wrote:
> On Fri, Jan 26, 2018 at 7:45 AM, Michael Paquier
> wrote:
>> There could be value in having a version dedicated to inheritance trees
>> as well, true enough. As well as value in having something that shows
>> both. Still let's not forget that partition se
On 2018/01/27 0:30, Robert Haas wrote:
> On Thu, Jan 25, 2018 at 8:44 PM, Amit Langote
> wrote:
>> Attached updated patch.
>
> I wonder if this patch is just parser bloat without any real benefit.
> It can't be very common to want to partition on a Boolean column, and
&
On 2018/01/27 1:31, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 26, 2018 at 11:07 AM, Stephen Frost wrote:
>>> I've already had two people mention that it'd be neat to have PG support
>>> it, so I don't believe it'd go unused. As for if we should force people
>>> to use quotes, my vote
Fujita-san,
On 2018/01/29 15:15, Etsuro Fujita wrote:
> (2018/01/29 9:50), Amit Langote wrote:
>> On 2018/01/26 21:31, Etsuro Fujita wrote:
>>> Attached is a modified
>>> version of the patch. What do you think about that? Please let me know.
>>> If that
Hi Alvaro.
On 2018/01/23 7:55, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Version 4 of this patch, rebased on today's master.
With the latest patch, I noticed what I think is an unintended behavior.
create table p (a int, b int) partition by list (a);
create table p1 partition of p for val
On 2018/01/19 23:55, Alvaro Herrera wrote:
> Local partitioned indexes
>
> Modified Files
> --
> doc/src/sgml/catalogs.sgml| 23 +
> doc/src/sgml/ref/alter_index.sgml | 14 +
> doc/src/sgml/ref/alter_table.sgml | 8 +-
> doc/src/sgml/ref/create_index.sgm
On 2018/01/29 16:28, Amit Langote wrote:
> create table p (a int, b int) partition by list (a);
> create table p1 partition of p for values in (1) partition by range (b);
> create table p11 partition of p1 for values from (1) to (10);
> create table p2 partition of p for values in (2);
Hi Jesper.
On 2018/01/29 22:13, Jesper Pedersen wrote:
> Hi Amit,
>
> On 01/26/2018 04:17 AM, Amit Langote wrote:
>> I made a few of those myself in the updated patches.
>>
>> Thanks a lot again for your work on this.
>>
>
> This needs a rebase.
AFAICS,
Fujita-san,
On 2018/01/30 18:22, Etsuro Fujita wrote:
> (2018/01/25 18:52), Amit Langote wrote:
>> On 2018/01/25 18:30, Etsuro Fujita wrote:
>>> The patches apply cleanly and compile successfully, but make check fails
>>> in an assert-enabled build.
>>
>
On 2018/01/30 5:30, Peter Eisentraut wrote:
> On 1/23/18 17:10, Alvaro Herrera wrote:
>> The main question is this: when running the trigger function, it is
>> going to look as it is running in the context of the partition, not in
>> the context of the parent partitioned table (TG_RELNAME etc). Th
On 2018/01/31 9:44, Peter Eisentraut wrote:
> On 1/30/18 04:49, Amit Langote wrote:
>>> If you are writing a generic
>>> trigger function, maybe to dump out all columns, you want to know the
>>> physical table and its actual columns. It's easy[citation needed]
Horiguchi-san,
Thanks for the review.
On 2018/01/30 20:43, Kyotaro HORIGUCHI wrote:
> At Tue, 30 Jan 2018 09:57:44 +0900, Amit Langote wrote:
>> AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [1]), compiles, and make
> I have some random comments on 0002.
>
> -extract_par
On 2018/02/01 6:08, Robert Haas wrote:
> On Mon, Jan 29, 2018 at 1:22 AM, Amit Langote
> wrote:
>>> Updated patch attached. Because I made no changes
>>> other than that, I'll make this as Ready for Committer.
>> Thanks a lot for reviewing.
>
> Comm
Hi.
When addressing a review comment on the fast partition pruning thread [1],
I noticed that specifying null in the IN-list will cause constraint
exclusion to wrongly fail to refute a table's check predicate.
create table foo (a int check (a = 1));
insert into foo values (null), (1);
-- ExecEva
Thanks for the comments.
On 2018/02/01 16:40, Ashutosh Bapat wrote:
> On Thu, Feb 1, 2018 at 12:26 PM, Amit Langote
> wrote:
>> Hi.
>>
>> When addressing a review comment on the fast partition pruning thread [1],
>> I noticed that specifying null in the IN-list will
On 2017/12/11 14:31, Amit Langote wrote:
> On 2017/12/09 3:46, Robert Haas wrote:
>> On Fri, Dec 8, 2017 at 5:40 AM, Amit Langote wrote:
>>> I noticed that if you partition using a array type column, partition
>>> pruning using constraint exclusion fails to work due
On 2018/01/29 14:57, Tom Lane wrote:
> Amit Langote writes:
>> Partition bound literals as captured gram.y don't have any type
>> information attached.
>
> Isn't that design broken by definition? TRUE is not the same thing
> as 't', nor as 'tr
Hi David.
On 2018/02/01 8:57, David Rowley wrote:
> On 31 January 2018 at 21:03, Amit Langote
> wrote:
>> Update patch set attached. Thanks again.
>
> (My apologies for being slow to respond here. I've been on leave this
> week and I'm off again next week. I
On 2018/02/02 19:41, Stephen Frost wrote:
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2018/01/23 8:57, Thomas Munro wrote:
>>> Here's an update to move the new stuff to the correct side of the
>>> closing "". Builds for me, and the type
On 2018/02/05 13:20, Ashutosh Bapat wrote:
> On Thu, Feb 1, 2018 at 2:23 PM, Amit Langote
> wrote:
>>
>> Yeah, the patch in its current form is wrong, because it will give wrong
>> answers if the operator being used in a SAOP is non-strict. I modified
>> the patch t
Fujita-san,
Thank you for the review.
On 2018/02/02 19:56, Etsuro Fujita wrote:
> (2018/01/30 18:52), Etsuro Fujita wrote:
>> (2018/01/30 18:39), Amit Langote wrote:
>>> Will wait for your comments before sending a new version then.
>>
>> Ok, I'll p
Hi.
Fujita-san pointed out in a nearby thread [1] that EXPLAIN ANALYZE shows
duplicate stats for partitions' triggers.
Example:
create table p (a int) partition by list (a);
create table p1 partition of p for values in (1);
create table p2 partition of p for values in (2);
create table p3 partit
On 2018/02/05 19:43, Etsuro Fujita wrote:
> (2018/02/05 14:34), Amit Langote wrote:
>> On 2018/02/02 19:56, Etsuro Fujita wrote:
>>> * In ExecInitPartitionResultRelInfo:
>>> + /*
>>> + * Note that the entries in this list appear in no predetermin
On 2018/02/06 10:48, Amit Langote wrote:
> When working on this, I wondered if the es_leaf_result_relations should
> actually be named something like es_tuple_routing_result_rels, to denote
> the fact that they're created by tuple routing code. The current name
> might lead to
Thank you both for the review.
I updated the comment in ExecSetupPartitionTupleRouting considering the
point both of you raised.
About renaming es_leaf_result_relations to
es_tuple_routing_result_relations, I will defer that to committer. But on
second though, maybe we don't need to make this pa
On 2018/02/06 13:56, Amit Khandekar wrote:
> I was wondering whether the same duplicate result rels issue can arise
> for es_root_result_relations and es_result_relations. But I think for
> inserts, es_root_result_relations is NULL, and for updates, these two
> lists always have distinct set of rel
On 2018/02/03 6:05, Robert Haas wrote:
> On Fri, Feb 2, 2018 at 9:33 AM, Robert Haas wrote:
>>> Updated set of patches attached (patches 0002 onward mostly unchanged,
>>> except I incorporated the delta patch posted by David upthread).
>>
>> Committed 0001. Thanks.
>
> Some preliminary thoughts.
Thanks for the review.
On 2018/02/08 0:04, Robert Haas wrote:
> On Tue, Feb 6, 2018 at 12:52 AM, Amit Langote
> wrote:
>> About renaming es_leaf_result_relations to
>> es_tuple_routing_result_relations, I will defer that to committer. But on
>> second though, maybe we
Hi Ashutosh.
On 2018/02/07 13:51, Ashutosh Bapat wrote:
> Here's a new patchset with following changes
>
> 1. Rebased on the latest head taking care of partition bound
> comparison function changes
I was about to make these changes myself while revising the fast pruning
patch. Instead, I decide
On 2018/02/08 11:55, Amit Langote wrote:
> Hi Ashutosh.
>
> On 2018/02/07 13:51, Ashutosh Bapat wrote:
>> Here's a new patchset with following changes
>>
>> 1. Rebased on the latest head taking care of partition bound
>> comparison function changes
>
&
601 - 700 of 2506 matches
Mail list logo
