On Tue, Nov 28, 2017 at 3:04 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Fri, Nov 24, 2017 at 10:28 PM, Antonin Houska <a...@cybertec.at> wrote:
>> Masahiko Sawada <sawada.m...@gmail.com> wrote:
>>
>>> On Mon, Oct 30, 2017 at 5:48 PM, Ashutosh
dren with different order of partition key columns, I meant
something like this
parent(a int, b int, c int) partition by (a), child1(b int, c int, a
int) partition by b, child1_1 (c int, a int, b int);
where the attribute numbers of the partition keys in different
children are different.
>>
o all columns being selected.
But that's not true, since DISTINCT ON would eliminate any duplicates in the
columns listed in that clause, effectively deduplicating the row being
selected. So, we are good there. May be you want to add a testcase with
DISTINCT ON.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
tal join tuple (local table joined with foreign
join) still qualifies. We do this by locally joining those rows again.
[1] is where the discussion started
[1] https://www.postgresql.org/message-id/558a18b3.9050...@lab.ntt.co.jp
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
lobal
rethink in the context of owner privileges problem being discussed
here.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Nov 29, 2017 at 7:42 PM, Stephen Frost <sfr...@snowman.net> wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost <sfr...@snowman.net> wrote:
>> > The "global rethink&q
On Thu, Nov 30, 2017 at 9:00 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Thu, Nov 30, 2017 at 8:50 AM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> On Fri, Mar 24, 2017 at 10:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
&
On Sat, Dec 2, 2017 at 1:11 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Dec 1, 2017 at 12:21 AM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> On Wed, Sep 13, 2017 at 4:07 PM, Ashutosh Bapat
>> <ashutosh.ba...@enterprisedb.com> wrote:
>
of consistency and to make sure the in future the code
remains sane if we change the way we store greatest modulus in
PartitionBoundInfoData in future.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From 6aba3444b75f3420af52f602d7a2f53da8da0847 Mon Sep 17 00:00:00
s without password
authentication, so always specify the password
option for user mappings that may be used by non-superusers." But
which user mappings may be used by non-superusers can not be defined
without explaining views owned by superusers. I don't think we should
be talking about views in
On Tue, Dec 5, 2017 at 11:20 AM, Julien Rouhaud <rjuju...@gmail.com> wrote:
> + * PartitionBoundInfoData structures for two partitioned table with
> exactly same
>
> should be "tables".
Sorry. Thanks for pointing it out. fixed in the attached patch.
--
Best Wishes,
Like a normal function
invocation, an aggregate invocation should not be allowed in a CALL
statement. Here's patch to fix it. I thought that window function
invocations and casts had similar problem, but they are prohibited by
backend grammar.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The
On Thu, Dec 14, 2017 at 8:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes:
>> We allow a function to be invoked as part of PERFORM statement in plpgsql
>> ...
>> But we do not allow a procedure to be inv
>>
>>> On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes:
>>> >> We allow a function to be invoked as part of PERFORM statement in
>>> >> plpgs
On Thu, Dec 14, 2017 at 4:01 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> +
> +-- Test when input relation for grouping is dummy
> +EXPLAIN (COSTS OFF)
> +SELECT c, sum(a) FROM pagg_tab WHERE 1 = 2 GROUP BY c;
> +
On Thu, Dec 14, 2017 at 9:40 PM, David G. Johnston
<david.g.johns...@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure <mmonc...@gmail.com> wrote:
>>
>> On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> > Ashut
On Thu, Dec 14, 2017 at 4:01 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
>
> +
> +EXPLAIN (COSTS OFF)
> +SELECT a FROM pagg_tab GROUP BY a ORDER BY 1;
> + QUERY PLAN
> +-
> + Group
&
be invoked directly without any quoting and CALL
decoration.
[1]
https://www.postgresql.org/docs/devel/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Dec 13, 2017 at 6:37 PM, Jeevan Chalke
<jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Tue, Dec 12, 2017 at 3:43 PM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>>
>> Here are review comments for 0009
>
>
> Thank you, Ashutosh for
On Tue, Dec 5, 2017 at 1:24 PM, Rajkumar Raghuwanshi
<rajkumar.raghuwan...@enterprisedb.com> wrote:
> On Tue, Dec 5, 2017 at 11:04 AM, Rajkumar Raghuwanshi
> <rajkumar.raghuwan...@enterprisedb.com> wrote:
>> On Mon, Dec 4, 2017 at 7:34 AM, Ashutosh Bapat
>> <ashut
inst 64 partitions are really bad. That's almost
2x slower.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
the GROUP BY
Reword as "... the partition key expressions match with "
This isn't a full review of 0007, but I think it covers most of the new
functionality.
[1]
https://www.postgresql.org/message-id/CAFjFpRdUz6h6cmFZFYAngmQAX8Zvo+MZsPXidZ077h=gp9b...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
gregate to be pushed
> into the foreign server, or;
> b) Spin up your own thread now, with reference to this patch as a
> prerequisite to your own patch.
>
> I agree that what you're talking about is quite exciting stuff, but
> please, let's not talk about it here.
>
+1 for all that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
pdateStmt
+UpperPathExtraData
UpperRelationKind
UpperUniquePath
UserAuth
Do we commit this file as part of the feature?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ut that too can be avoided. That
would reduce the size of patch a bit.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
untry.name and calendar.year are the partition keys partition
pruning would identify the needed partitions from those tables. But
planner doesn't know that calendar.year is somehow related to
calendar.id and then transfer that knowledge so that partitions of
sales can be identified.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Sat, Dec 2, 2017 at 4:08 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Dec 1, 2017 at 7:41 AM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>> This code creates plans where there are multiple Gather nodes under an Append
>> node.
>
outerrel->relids,
innerrel,
jointype,
restrictlist,
false);
break;
Do you have a testcase, which shows
hat.
>
> Best regards,
> Etsuro Fujita
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
on-wise join with partitioned tables", but I felt
> that the partition planning code is in such a state of flux at the
> moment that I feared that comment might get outdated again someday in
> the near future.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, Dec 11, 2017 at 2:42 PM, David Rowley
<david.row...@2ndquadrant.com> wrote:
> On 11 December 2017 at 21:18, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>> On Thu, Dec 7, 2017 at 5:11 AM, David Rowley
>> <david.row...@2ndquadrant.com> wr
and appending the
results. That's a lot of work and quite some new infrastructure. Each
of those join will pick unique key if appropriate index exists on the
partitions.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Fri, Dec 8, 2017 at 12:25 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Dec 5, 2017 at 1:03 AM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>> Sorry. Thanks for pointing it out. fixed in the attached patch.
>
> + * The datum
opt_boolean_or_string instead of TRUE_P and
FALSE_P. It also supports ON and OFF, which will be bonus.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
gets are not specific to any path, but will be
applicable to all the paths created for that rel.
On Mon, Dec 4, 2017 at 7:44 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Sat, Dec 2, 2017 at 4:08 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On F
l#GUC-SEQ-PAGE-COST>,
random_page_cost
<https://www.postgresql.org/docs/10/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST>,
effective_io_concurrency
<https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY>).".
This means the tablespace specific values will override the ones in
configuration i.e. postgresql.conf. Answer to your question is yes.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
number of elements, unnest, array_agg combination might win for
large number of elements. Have you tried that?
If we try to improve unnest, array_agg combination for small array, we
will get consistent performance without any additional syntax.
Although, I admit that query involving unnest and array_agg is not
very readable.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, May 14, 2018 at 10:21 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Fri, May 11, 2018 at 6:31 PM, Etsuro Fujita
> <fujita.ets...@lab.ntt.co.jp> wrote:
>>
>> I guess you forgot to show the query.
>
> Sorry. Here's the query.
>
> e
e will change it in near future once the memory
consumption issue has been tackled. The features are useful and users
would want those to be enabled by default like other query
optimizations. So, we can't take a decision based on that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Tue, May 1, 2018 at 5:00 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
> (2018/04/27 14:40), Ashutosh Bapat wrote:
>>
>> Here's updated patch set.
>
>
> Thanks for updating the patch! Here are my review comments on patch
> 0003-postgres_fdw-ch
ed table since not all
partitions have a given index when one of those is a foreign
partition.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ng like:
>
> - If we want to update/delete remote partitioned/inhtance tables
> without direct modify, the foreign relation must have a columns
> defined as "tableoid as remote_tableoid" or something. (We
> could change the column name by a fdw option.)
Ok. I think, I
On Thu, Apr 26, 2018 at 7:08 PM, Amit Langote <amitlangot...@gmail.com> wrote:
> On Thu, Apr 26, 2018 at 9:54 PM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>> On Thu, Apr 26, 2018 at 1:08 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>
.
0001 is the actual testcase and the output
0002 adds warnings where EEOP_OUTER/INNER_SYSVAR are used. This patch
is not for commit. It is only to make sure that the code gets
exercised by the test. When both the patches are applied, the test
shows those warnings.
--
Best Wishes,
Ashutosh Bapat
On Wed, May 9, 2018 at 5:20 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
>
> (2018/04/25 18:51), Ashutosh Bapat wrote:
>> Actually I noticed that ConvertRowtypeExpr are used to cast a child's
>> whole row reference expression (not just a Var node) in
On Thu, May 10, 2018 at 6:23 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
> (2018/05/10 13:04), Ashutosh Bapat wrote:
>>
>> On Wed, May 9, 2018 at 5:20 PM, Etsuro Fujita
>> <fujita.ets...@lab.ntt.co.jp> wrote:
>>>
>>> (2018/04/25
On Thu, May 17, 2018 at 11:56 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>> The second would mean that SELECT * from foreign table reports
>> remotetabl
On Thu, May 17, 2018 at 4:50 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
> (2018/05/16 22:49), Ashutosh Bapat wrote:
>>
>> On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita
>> <fujita.ets...@lab.ntt.co.jp> wrote:
>>>
>>> However, consider
ctionality to ship
generic expressions and not just Vars in future. Usually we would be
searching for columns in the subquery targetlist so the name change
looks good to me. IIRC, the function was added one release back, so
backpatching pain, if any, won't be much. But I don't think we should
carry a
d I
>> don't want to copy that knowledge everywhere.
>
> Maybe something like:
>
> ereport(promote_eio_to_panic(ERROR), ...)
Well, searching for places where error is reported with level PANIC,
using word PANIC would miss these instances. People will have to
remember to search with promote_eio_to_panic. May be handle the errors
inside FileSync() itself or a wrapper around that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, May 16, 2018 at 11:31 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Apr 16, 2018 at 7:35 AM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
>> It does fix the problem. But the patch as is interferes with the way
>> we handle tableoid cu
ve been intended in
> a particular SQL statement. There are cases where something must
> "become all one thing or all the other", but I don't see why that
> should be true here.
+1 for all that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
_eio_to_panic(), and someone could trivially look up all
> the callers of that function then.
It's not just grep, but tools like cscope, tag. Although, I agree,
that adding a function, if all necessary, is more important than
convenience of finding all the instances of a certain token easily.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
port 2PC which may not be possible.
> If it needs to be called by all
> FDWs, then it breaks existing FDWs that don't call it.
>
That's true. By default FDWs, which do not want to use this facility,
can just pass false without any need for further change.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ems to be a preferred style in the code.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
PDATE causes a row to move ..."
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
omething like that. I agree that seeing a
ForeignScan in the plan is not a good thing.
Anyway, the work involved in my proposal may not be worth the utility
we get out of this extension, so may not be worth pursuing it further.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
this
> acceptable. If we cannot avoid these assumptions, they need to be
> documented more centrally, like in the relation.h block comment for struct
> AppendRelInfo.
>
Attached patch adds the assumption to the block you mention above. Please check.
--
Best Wishes,
Ashutosh Bapat
Ent
gt; extra storage moves together with tuples or prevent sorts or
> something like from being inserted there.
I think your approach still has the same problem that it's abusing the
tableOid field in the heap tuple to store tableoid from the remote as
well as local table. That's what Robert and
On Thu, Jun 7, 2018 at 10:58 AM, Amit Langote
wrote:
> On 2018/06/07 14:17, Ashutosh Bapat wrote:
>>> that is, users can find out about that feature by themselves by
>>> trying it out?
>>
>> I didn't understand that part.
>>
>> Probably we just s
ro.com/list/id/cafjfprcmwwepj-do1otxq-gapgpsz1fmh7yqvqtwzqogczq...@mail.gmail.com
[2]
https://postgrespro.com/list/id/cafjfprcmwwepj-do1otxq-gapgpsz1fmh7yqvqtwzqogczq...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Jun 14, 2018 at 1:54 PM, Amit Langote
wrote:
> On 2018/06/12 22:22, Ashutosh Bapat wrote:
>> -- create triggers, user may create different trigger functions one
>> for each partition, unless s/he understands that the tables can share
>> trigger functions
>>
tions from different sessions. Also, what
should happen to the partitions from the other session after the
session creating the temporary partitioned table goes away is not
clear to me. Should they get dropped, how?
If I am reading Tom's reply upthread correctly, we should not allow
creating a temporary part
mporary partitions are?
Should we just prohibit adding temporary partitions to a permanant
partitioned table? We should allow adding temporary partitions to a
temporary partitioned table if only they both belong to the same
session.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
create
trigger on the partitioned table.
May be I am underestimating users but I am sure there will be some
users who will end up with scenario.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ion states. I haven't looked at the patch to exactly figure out
which of these is true.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, Jun 11, 2018 at 4:05 PM, Etsuro Fujita
wrote:
> (2018/06/07 19:42), Ashutosh Bapat wrote:
>>
>> On Wed, Jun 6, 2018 at 5:00 PM, Etsuro Fujita
>> wrote:
>>>
>>> Since I'm not 100% sure that that is the right way to go, I've been
>>> rethi
On Thu, Jun 14, 2018 at 6:49 PM, Robert Haas wrote:
> On Wed, Jun 6, 2018 at 7:51 AM, Ashutosh Bapat
> wrote:
>> On Tue, Jun 5, 2018 at 10:38 PM, Alvaro Herrera
>> wrote:
>>
>>> - BEFORE row triggers are not supported
>>
>> I think this is fine
thout any warning or notice. That's fine if the trigger changes the
salaries to $50K but not OK if each of those increases salary by 10%.
The database has limited ability to recognize what a trigger is doing.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Tue, Jun 12, 2018 at 8:49 AM, Kyotaro HORIGUCHI
wrote:
> Thanks for the discussion.
>
> At Thu, 7 Jun 2018 19:16:57 +0530, Ashutosh Bapat
> wrote in
>
>> On Tue, Jun 5, 2018 at 3:40 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello.
>> >
>> &
RAM_EXECs can not be folded into constant at execution
start since those not assigned any values yet. AFAIU expressions,
within a given node, with those parameters can be folded into
constants (if possible) during ExecRewind() on that node. We have to
perform pruning just before the (Merge)Append nod
appropriate for one child-join. But, it's certainly fine to add a
> comment.
That didn't occurred to me as well.
Here's patch with comments and Assertions added to check the
non-overlapping AppendRelInfos. The assertions check that same parent
or child doesn't appear more than once in a
e we want
to create temporary objects (we don't have support to create temporary
foreign tables for now, but may be that's desirable feature) or create
them in a different database to reduce catalog bloat. Similarly we
won't be able to create indexes on the foreign table, but may be we
could simulat
ust that configuration doesn't provide much
scalability. With each node functioning as coordinator (facing
clients) and worker (facing other coordinators) keeps the number of
nodes to a minimum. It is good for HA.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
dra
>
> Congratulations to all!
>
> regards, tom lane
>
Congratulations to all.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Fri, Jun 1, 2018 at 7:43 AM, Kyotaro HORIGUCHI
wrote:
> On Thu, May 31, 2018 at 11:34 AM, Ashutosh Bapat
> wrote:
>> On Thu, May 31, 2018 at 7:36 PM, Tom Lane wrote:
>>> What you want for the first part of that is basically like
>>> generate_new_param() in
or some such method to create replicas of tables on
multiple nodes in a cluster and let the optimizer take advantage of
that for join push-down or load balancing.
>
> Some of the above may end up with XL's things like
> pgxc_node/pgxc_group system tables, pgxc_ctl command, CREATE/DROP
> NODE/NODE GROUP commands, etc.
>
I agree.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
═╡
> │ public │ data │ table │ pavel │ 0 bytes │ │
> └┴──┴───┴───┴─┴─┘
> (1 row)
I think we should at least display "Type" as "partitioned table" for a
partitioned table, so that it's easy to understand why the size is 0;
partitioned tables do not hol
On Sat, Jun 2, 2018 at 4:05 AM, Simon Riggs wrote:
> On 1 June 2018 at 16:56, Ashutosh Bapat
> wrote:
>> On Fri, Jun 1, 2018 at 11:10 AM, Simon Riggs wrote:
>>>
>>> Using a central coordinator also allows multi-node transaction
>>>
V12 material.
Partition pruning will use that feature. I don't think we should make
partition pruning work with stable expressions in some ad-hoc way in
V11 and the some future release (mostly V12) implements it on top of
stable expression folding feature. So my vote for making it work in
V12.
--
Be
pplicable to the new partitions created.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Tue, Jun 5, 2018 at 5:50 AM, David Rowley
wrote:
> On 5 June 2018 at 01:35, Ashutosh Bapat
> wrote:
>> I was wondering if we can get rid of append_rel_list altogether. In
>> your patch, you have saved AppendRelInfos by child_relid. So all the
>> slots indexed by pa
ies back to -09, but that seems like less churn
> than the other way.
>
Notes at [1] about keeping this commitfest for small patches. Just
renaming the commitfest would mean all the patches, big and small, can
be reviewed and committed.
[1] https://wiki.postgresql.org/wiki/PgCon_2018_Develop
99
Planning Time: 0.424 ms
Execution Time: 0.139 ms
(14 rows)
The scan on t1p1 x returns no rows and should have been pruned since
y.b + 100 is constant for a given y.b.
But for this to work, folding constant expressions doesn't help since
y.b changes with every rescan of t1 x. So may be we n
On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote:
> From: Ashutosh Bapat
>> In order to normalize parse trees, we need to at
>> least replace various OIDs in parse-tree with something that the
>> foreign server will understand correctly like table name on the
>> foreig
On Wed, Jun 6, 2018 at 8:11 AM, Thomas Munro
wrote:
> On Mon, Mar 5, 2018 at 8:13 PM, Rajkumar Raghuwanshi
> wrote:
>> On Wed, Feb 7, 2018 at 2:00 PM, Ashutosh Bapat
>> Changed partition-wise statement to partitionwise.
>> Attached re-based patch.
>>
>>> Th
nshi
> QMG, EnterpriseDB Corporation
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Jun 6, 2018 at 8:16 PM, MauMau wrote:
> From: Ashutosh Bapat
>> Keeping OIDs same across the nodes would require extra communication
>> between nodes to keep track of next OID, dropped OIDs etc. We need
> to
>> weigh the time spent in that communication a
On Wed, Jun 6, 2018 at 11:46 PM, Alvaro Herrera
wrote:
> On 2018-Jun-06, Ashutosh Bapat wrote:
>
>> On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote:
>> > From: Ashutosh Bapat
>> >> In order to normalize parse trees, we need to at least replace
>> >&
st to partition_prune.sql that verifies a similar case.
Thanks for taking care of that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Jun 7, 2018 at 7:51 AM, Amit Langote
wrote:
> On 2018/06/06 20:51, Ashutosh Bapat wrote:
>> The existing wording suggests that the user
>> creates the triggers on the partitioned table, and that will be
>> supported always, which can lead to problems.
>
> Do you
On Thu, Jun 7, 2018 at 10:53 AM, Michael Paquier wrote:
> On Thu, Jun 07, 2018 at 10:28:15AM +0530, Ashutosh Bapat wrote:
>> On Wed, Jun 6, 2018 at 8:16 PM, MauMau wrote:
>>> Looking at the XL source code, the following sequence of functions are
>>> called when the
oblems, I don't think we could afford not to
cover a child whole-row reference in ConvertRowtypeExpr.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
I am not sure if this can b e squeezed into HEAD right now. It looks
safe to do so. But in case not, please add this to the next commitfest
so that it's not forgotten.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
distribution of data for joins.
I think partitioning + FDW provide basic infrastructure for
distributing data, planning queries working with such data. We need
more glue to support node management, cluster configuration. So, I
agree with your statement. But I think it was clear from the beginning
that
On Fri, Jun 1, 2018 at 11:27 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> In order to avoid double parsing, we might want to find a way to pass
>> a "normalized" parse tree down to the foreign server. We need to
>> normalize the OIDs in the parse tree since t
t at all. If we could do that then it's matter of using
same methods as plan-time partition pruning to prune the partitions.
If we go ahead with this patch, we should at least update it to handle
stable functions for the sake of completeness.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
silent corruption that happens today
and should be back-portable.
[1]
https://www.postgresql.org/message-id/CAFjFpRfK69ptCTNChBBk+LYMXFzJ92SW6NmG4HLn_1y7xFk=k...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
itself reads like "can not drop constraint
"p_a_check" on relation "p1" inherited from "partitioned table's name"
OR a hint "you may drop constraint "p_a_check" on the partitioned
table "partitioned table's name". It might even suffice to say
"partition p1" instead "relation p1" so that the user gets a clue.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
nd an
> output slot that each will keep their slot descriptors set.
+1 for that.
But I am worried that the code will have to create thousand slots if
there are thousand partitions. I think we will need to see how much
effect that has.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
1 - 100 of 932 matches
Mail list logo
