On Mon, Sep 4, 2017 at 10:04 AM, Amit Langote
wrote:
> On 2017/09/04 12:38, Etsuro Fujita wrote:
>> On 2017/09/02 4:10, Ashutosh Bapat wrote:
>>> This rebase mainly changes patch 0001, which translates partition
>>> hierarchy into inheritance hierarchy creating AppendR
On Mon, Sep 4, 2017 at 10:34 AM, Amit Langote
wrote:
> Hi Ashutosh,
>
> On 2017/09/04 13:51, Ashutosh Bapat wrote:
>> Hi,
>> Thomas's application to track patches told me that this patch needs
>> rebase. It also required some changes to the code. Here's th
Hi,
Thomas's application to track patches told me that this patch needs
rebase. It also required some changes to the code. Here's the updated
version. I have squashed those two patches together.
On Tue, Mar 14, 2017 at 6:35 PM, Ashutosh Bapat
wrote:
> Added this to 2017/7 commitf
PFA the patches rebased on the latest sources. There are also fixes
for some of the crashes and bugs reported. I haven't yet included the
testcase patch in the main patchset.
On Mon, Aug 28, 2017 at 12:44 PM, Rajkumar Raghuwanshi
wrote:
> On Mon, Aug 21, 2017 at 12:43 PM, Ashutosh Bapat
On Thu, Aug 31, 2017 at 1:15 AM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 12:47 PM, Ashutosh Bapat
> wrote:
>> +1. I think we should just pull out the OIDs from partition descriptor.
>
> Like this? The first patch refactors the expansion of a single child
> out into a s
tchInfo at all. Maybe that's actually a
> better plan anyway, because as Ashutosh points out, we don't want the
> partitioned children to show up before the unpartitioned children in
> the resulting ordering.
>
+1. I think we should just pull out the OIDs from partition descripto
as their OIDs would be returned by
RelationGetPartitionDispatchInfo(). I have a feeling that, if we go
that route, we will replace almost all the changes that Amit Langote's
patches do to expand_inherited_rtentry().
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Databa
onConstraints() to scan the relation or add to the
queue based on some input flag may be wqueue argument itself. But I
haven't thought through this completely. Any thoughts?
>>
>> 0004:
>> Extend default partitioning support to allow addition of new partitions
>> after
&
ady
recursive, so if we process expansion and pruning for one level in
those functions, the recursion will automatically take care of doing
so for every level.
>
>
> Note that this is still largely a WIP patch and the implementation details
> might change per both the feedback here and
n OFFSET clause
even when it's possible to push it down.
If we could defer deparsing the query to execution time we might be
able to achieve both the targets. It has one more advantage: we could
pass parameters embedded in the query, rather than binding them.
--
Best Wishes,
Ashut
ing base relations as well. I have not spent time looking
for what it takes to support these cases. For now the patch does not support
partition-wise join in such cases.
TODOs
---
1. Add tests for advanced partition matching algorithm
2. Improve code quality, commenting, function names etc.
[1
On Sat, Aug 19, 2017 at 1:21 AM, Robert Haas wrote:
> On Fri, Aug 18, 2017 at 1:17 AM, Ashutosh Bapat
> wrote:
>> 0004 patch in partition-wise join patchset has code to expand
>> partition hierarchy. That patch is expanding inheritance hierarchy in
>> depth first manne
et I don't see the
reason for expanding in partitioned tables first order. Can you please
elaborate if we still need to expand in partitioned table first
manner? May be we should just address the expansion issue in 0004
instead of dividing it in two patches.
--
Best Wishes,
Ashutosh Bapat
Ente
s://www.postgresql.org/message-id/cafjfprcemmx26653xfayvc5kvqcrzckscvfqzdbxv%3dkb8ak...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAFjFpRefs5ZMnxQ2vP9v5zOtWtNPuiMYc01sb1SWjCOB1CT=u...@mail.gmail.com
[3]
https://www.postgresql.org/message-id/CAFjFpRd6Kzx6Xn%3D7vdwwnh6rEw2VEgo--iP
l.org/message-id/cafjfprfkr7igcgbbwh1pq__w-xpy1o79y-qxcmjc6fizlqf...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAFjFpRdXn7w7nVKv4qN9fa%2BtzRi_mJFNCsBWy%3Dbd0SLbYczUfA%40mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
This
looks like a feature (support copy to and from a foreign table) to be
handled by itself.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 17, 2017 at 10:54 AM, Amit Langote
wrote:
> On 2017/08/17 13:56, Ashutosh Bapat wrote:
>> On Thu, Aug 17, 2017 at 8:06 AM, Amit Langote
>> wrote:
>>> On 2017/08/17 11:22, Robert Haas wrote:
>>>> On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote
>&g
if the child table (one with the OID inhrelid) is
> partitioned, inhpartitioned seems best to me. Will implement that.
inhchildpartitioned is long but clearly tells that the child table is
partitioned, not the parent. pg_inherit can have parents which are not
partitioned, so it's bette
e, may be we
should use a local variable
Form_pg_inherits inherits_tuple = GETSTRUCT(inheritsTuple);
and use that to fetch its members.
I am still reviewing changes in this patch.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From e9ad9f947d6d553ce8ec29feb8560df
On Tue, Aug 15, 2017 at 10:15 PM, Robert Haas wrote:
> On Thu, Aug 10, 2017 at 8:00 AM, Ashutosh Bapat
> wrote:
>> Attached patches with the comments addressed.
>
> I have committed 0001-0003 as 480f1f4329f1bf8bfbbcda8ed233851e1b110ad4
> and e139f1953f29db245f60a7acb72fcc
. Maybe
>> drop that prefix? It should be clear from the context that this is a
>> message from the LDAP layer.
>
> I think making it visible that the message comes from LDAP (rather than
> Postgres or anything else) is valuable. How about this?
>
> LOG: could n
row expressions getting translated using ConvertRowExpr, which
are not expected to pop up in a scan's targetlist. So we can't
eliminate the Append node.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/src/backend/optimizer/prep/pre
ized views. Attached patch adds
materialized views to column_privileges view along with your changes.
Please add this to the next commitfest so that it doesn't get forgotten.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/src/backend/catal
On Thu, Aug 10, 2017 at 3:13 PM, Thomas Munro
wrote:
> On Thu, Aug 10, 2017 at 6:23 PM, Ashutosh Bapat
> wrote:
>> Your patch didn't improve planning time without partition-wise join,
>> so it's something good to have along-with partition-wise join. Given
>>
n we created thousands of children, we have certainly crossed the
few hundred threashold. So, there may be other optimizations possible
there. Probably we should leave that out of partition-wise join
patches. Do you think we solving this problem is a prerequisite for
partition-wise join? Or should
add this to the next commitfest.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 3, 2017 at 9:38 PM, Ashutosh Bapat
wrote:
> On Thu, Aug 3, 2017 at 2:10 AM, Robert Haas wrote:
>> On Mon, Jul 31, 2017 at 7:59 AM, Ashutosh Bapat
>> wrote:
>>> Adding AppendRelInfos to root->append_rel_list as and when they are
>>> created wou
On Mon, Aug 7, 2017 at 11:18 AM, Ashutosh Bapat
wrote:
>>
>> One objection to this line of attack is that there might be a good
>> case for locking only the partitioned inheritors first and then going
>> back and locking the leaf nodes in a second pass, or even onl
titions too, you just go
> through the partitioned children in the order they were returned and
> find_inheritance_children(blah blah, false) on each one of them and
> the lock order is exactly consistent with what you would have gotten
> if you'd done find_all_inheritors(blah blah
into new functions get_all_inheritors() and
get_inheritance_children(). We may choose other names for functions.
The idea is to create routing functions/macros instead of sprinkling
code with if () else conditions.
[1]
https://www.postgresql.org/message-id/ca+tgmoberutu4osxa_ua4aorho83wxavfg8n1nqcof
g has_child in the patch and use
"real child" in the comment at the end to avoid repetition. But I want
to first check whether we want this fix or we can live with the Append
plan.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/src/backen
On Thu, Aug 3, 2017 at 2:10 AM, Robert Haas wrote:
> On Mon, Jul 31, 2017 at 7:59 AM, Ashutosh Bapat
> wrote:
>> Adding AppendRelInfos to root->append_rel_list as and when they are
>> created would keep parent AppendRelInfos before those of children. But
>> th
le. So, how about naming the option as
--unpartition-partitioned-table [partitioned-table-name, ] # if
names are omitted it defaults to all the partitioned tables.
That really says what dump is really doing without focusing on how the
data will be used like restoring/inserting/copying etc.
--
Bes
ations than that. As I
said, I haven't gone through all the places, so, I don't know the
whole picture yet. But given the number of places where we added
RELKIND_PARTITIONED_TABLE, I guess, there are more than one places
where at least some of those tests are used.
--
Best Wishes,
Ashut
oblems for translators.
>
> Yeah, the error messages that list a bunch of different relkinds in text
> form are going to be a hassle no matter what. Most of the ways you might
> think of to change that will violate our translatability rules.
>
Ok. I agree with that. May be f
On Wed, Aug 2, 2017 at 8:47 PM, Robert Haas wrote:
> On Mon, Jul 3, 2017 at 3:52 AM, Ashutosh Bapat
> wrote:
>>> I noticed, that
>>> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
>>> number of conditions to include this relkind. We
k_a check (a > 0) not valid);
>
> But, not OK in the following command:
>
> create foreign table ffoo (
> a int,
> constraint check_a check (a > 0) not valid
> ) server loopback options (table_name 'foo');
>
If the user has specified "not valid"
On Mon, Jul 31, 2017 at 8:32 AM, Robert Haas wrote:
> On Fri, Jul 14, 2017 at 3:02 AM, Ashutosh Bapat
> wrote:
>> Here's revised patch set with only 0004 revised. That patch deals with
>> creating multi-level inheritance hierarchy from multi-level partition
>> hie
0003 patch.
Having it in a separate patch would allow you to change its
implementation if needed.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jul 29, 2017 at 2:55 AM, Robert Haas wrote:
> On Fri, Jul 28, 2017 at 9:30 AM, Ashutosh Bapat
> wrote:
>> 0004 patch
>> The patch adds another column partdefid to catalog pg_partitioned_table. The
>> column gives OID of the default partition for a given partitio
in this case) to find out
the default partition's OID. That will be occasional performance hit
worth the otherwise maintenance burden.
I haven't reviewed next two patches, but those patches depend upon
some of the comments above. So, it's better to consider these comments
before l
o anything critical in
post-commit/abort phase. So we should device a way to send
COMMIT/ABORT prepared messages to the remote server in asynchronous
fashion carefully avoiding errors. Recent changes to 2PC have improved
performance in that area to a great extent. Relying on resolver
backend to resol
On Thu, Jul 27, 2017 at 12:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat
>> wrote:
>>> According to F.34.1.1 at [1] passing connection string as dbname
>>> option should work, so your question is valid. I a
or v10?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
some error
messages do not have any diagnostic information. In that case above
error detail may be confusing. May be we should just omit error
details when diagnostic message is not available.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
are not going to change current behaviour, we should
change the documentation and say that option dbname means "database
name" and not a connection string.
[1]
https://www.postgresql.org/docs/10/static/postgres-fdw.html#idm44880567492496
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporat
On Wed, Jul 26, 2017 at 11:08 AM, Rafia Sabih
wrote:
>
>
> On Wed, Jul 26, 2017 at 11:06 AM, Ashutosh Bapat
> wrote:
>>
>> On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih
>> wrote:
>> >
>> >
>> > On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh
On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih
wrote:
>
>
> On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat
> wrote:
>>
>> On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih
>> wrote:
>>
>> > Query plans for the above mentioned queries is attached.
>
lso, please include the query in
explain analyze output using -a or -e flats to psql. That way we will
have query and its plan in the same file for ready reference.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pg
o the index scan will be a bit faster. But only a
bit, since the depth of the index doesn't increase linearly with the
size of index.
Rrun-time partition pruning will improve performance even without
partition-wise join since partition pruning will be able to eliminate
all but one p
On Fri, Jul 21, 2017 at 10:39 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Fri, Jul 21, 2017 at 10:55 AM, Kyotaro HORIGUCHI
>> wrote:
>>> The attached patch differs only in this point.
>
>> +1. The patch looks good to me.
>
> Pushed with a couple a
/* hashvalue == 0 means a cache reset, must clear all state */
> + if ((hashvalue == 0) ||
> + ((cacheid == FOREIGNSERVEROID &&
> + entry->server_hashvalue == hashvalue) ||
> + (cacheid == USERMAPPINGOID &&
> + entry->
pend all the partitions of the
partitioned table and then join with the unpartitioned table.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
idth=8) (actual
> time=180858.448..180858.448 rows=119994608 loops=3)
>Buckets: 33554432
> Batches: 8 Memory Usage: 847911kB
>
> Overall, this doesn't look like a problem of partition-wise join patch
> itself.
>
Thanks for confirming it.
--
Bes
On Thu, Jul 20, 2017 at 5:30 PM, Thomas Munro
wrote:
> On Thu, Jul 20, 2017 at 11:47 PM, Ashutosh Bapat
> wrote:
>> On Thu, Jul 20, 2017 at 11:04 AM, Thomas Munro
>> wrote:
>>> On Fri, Jun 2, 2017 at 4:16 AM, Tom Lane wrote:
>>>> I don't think it do
only be equal to one of them.
The word "match" confusing. Google's dictionary entry gives "be equal
to (something) in quality or strength." as its meaning. May be we want
to reword it as "... LHS row must find a joining row in RHS ..."?
--
Best Wishes,
Ashutos
On Thu, Jul 20, 2017 at 11:46 AM, Amit Langote
wrote:
> On 2017/07/20 15:05, Ashutosh Bapat wrote:
>> On Wed, Jul 19, 2017 at 9:54 AM, Rafia Sabih
>> wrote:
>>>
>>> Partition information:
>>> Type of partitioning - single column range partition
&g
ivity estimation. It
might happen that some correction in selectivity estimation for
child-joins is required, but I have not spotted any code in
selectivity estimation that differentiates explicitly between child
and parent Vars and estimates. So, I am more inclined to believe
Thomas's theory.
hose next patches would refuse to
apply partition-wise join for range partitioned tables. So, I am
confused as to how come partition-wise join is being chosen even when
the number of partitions differ.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sen
On Thu, Jul 13, 2017 at 9:15 PM, Alvaro Herrera
wrote:
> Ashutosh Bapat wrote:
>
>> Happened to stumble across some instances of lfirst() which could use
>> lfirst_node() in planner.c. Here's patch which replaces calls to
>> lfirst() extracting node pointers
On Fri, Jul 14, 2017 at 2:04 PM, Kyotaro HORIGUCHI
wrote:
> Thank you for the comments.
>
> At Thu, 13 Jul 2017 16:54:42 +0530, Ashutosh Bapat
> wrote in
>
>> On Thu, Jul 13, 2017 at 2:53 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, moved to pgsql-hacker
o me. I haven't reviewed it
thoroughly though.
I noticed a type "suporious", I think you meant "spurious"? Probably
that comment should be part of the function which marks the connection
as invalid e.g. InvalidateConnectionForMapping().
pgfdw_xact_callback() reports the reaso
st Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
like Path, Plan etc.
2. those extract any node as Aggref, Var and then check using IsA()
3. those extracting some pointers other than nodes.
"make check" runs without any failure.
Are we carrying out such replacements in master or this will be
considered for v11?
--
Best Wishes,
On Wed, Jul 12, 2017 at 12:54 AM, Dean Rasheed wrote:
> On 11 July 2017 at 13:29, Ashutosh Bapat
> wrote:
>> +
>> + Also note that some element types, such as timestamp,
>> + have a notion of "infinity", which is just another value that can
>
On Wed, Jul 12, 2017 at 9:39 AM, Amit Langote
wrote:
> On 2017/07/12 12:47, Ashutosh Bapat wrote:
>> On Wed, Jul 12, 2017 at 8:23 AM, Amit Langote
>> wrote:
>>> On 2017/07/11 18:57, Ashutosh Bapat wrote:
>>>> On Tue, Jul 11, 2017 at 4:16 AM, David Fetter
On Wed, Jul 12, 2017 at 8:23 AM, Amit Langote
wrote:
> On 2017/07/11 18:57, Ashutosh Bapat wrote:
>> On Tue, Jul 11, 2017 at 4:16 AM, David Fetter wrote:
>>> So whatever we land on needs to mention partition_of and
>>> has_partitions. Is that latter just its immediat
be adding much value to the patch. Replacing RANGE_DATUM_NEG_INF
and RANGE_DATUM_POS_INF with PARTITION_RANGE_DATUM_MINVALUE and
PARTITION_RANGE_DATUM_MAXVALUE looks like a good change in line with
MINVALUE/MAXVALUE change. May be we should reuse the previous
variables, enum type name and except
oop anyway
And some portions of the comment before find_all_inheritors() in
ATExecAttachPartition() look duplicated in portions of the code that
check constraints on the table being attached and each of its leaf
partition.
Other than that the patches look good to me.
--
Best Wishes,
Ashutosh Bapat
E
s false. Whether something is partitioned and whether
>> it is a partition are independent concerns.
>
> So whatever we land on needs to mention partition_of and
> has_partitions. Is that latter just its immediate partitions?
> Recursion all the way down? Somewhere in b
atch.)
Not really. It sets the dummy path list in child, which won't be done
if we return without traversing append_rel_list, esp. when the parent
is marked dummy without marking any of its children dummy as explained
above.
But we could avoid marking a child dummy twice, in case the parent
ood
option. But I am open to suggestions.
What if we always mark the partition relations of a dummy partitioned table
dummy? I tried attached path on a thousand partition table, the planning time
increased by 3-5%. That doesn't look that bad for a thousand partitions.
Any other options/commen
049 * parent-rel Vars it'll be asked to emit.
1050 */
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> with patch:
> Bitmap Heap Scan on tenk1 (cost=4.39..39.52 rows=10 width=244) (actual
> time=0.074..0.142 rows=10 loops=1)
The actual time has increased even though estimation is correct.
Those differences may just vanish if we take average of multiple runs
and are not that importan
On Fri, Jun 30, 2017 at 2:53 PM, Rafia Sabih
wrote:
>
>
> On Mon, May 22, 2017 at 12:02 PM, Ashutosh Bapat
> wrote:
>>
>>
>> Here's set of patches rebased on latest head.
>
>
> In an attempt to test this set of patches, I found that not all of t
f OIDs returned. Thus for an unpartitioned relation being
attached, it will try to compare the constraints again. Am I correct?
+ * comparing it to similarly-processed qual clauses, and may fail
There are no "qual clauses" here only constraints :).
The testcase looks good to me.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nology seemed more consistent, e.g. "UNBOUNDED ABOVE" => no upper
> bound.
>
>
>> Also, I assume UNBOUNDED ABOVE signifies positive infinity and vice versa.
>>
>
> Right.
>
> I'm not particularly wedded to that terminology. I always find naming
>
Forgot to attach the patch with the earlier mail.
On Mon, Jul 3, 2017 at 1:22 PM, Ashutosh Bapat
wrote:
> On Mon, May 29, 2017 at 12:55 PM, Ashutosh Bapat
> wrote:
>>
>> --
>> I noticed, that
>> after we introduced RELKIND_PARTITIONED_TABLE, we required to chang
On Mon, May 29, 2017 at 12:55 PM, Ashutosh Bapat
wrote:
>
> --
> I noticed, that
> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
> number of conditions to include this relkind. We missed some places in
> initial commits and fixed those later. I am wo
+side
would cause confusion. Also LEFT/RIGHT may work for a single
dimensional datatype but not for multi-dimensional spaces. How about
MINIMUM/MAXIMUM or UNBOUNDED MIN/MAX to indicate the extremities.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent
have support for that and if not, will we
consider it for v10 or v11 and how.
>
> It's fine to use the previous partition's upper bound as the lower bound
> of the current partition, if the former does contain an UNBOUNDED value,
> because whereas a finite value divides the
On Fri, Jun 23, 2017 at 2:58 AM, Alvaro Herrera
wrote:
> Ashutosh Bapat wrote:
>> On Mon, Jun 5, 2017 at 8:22 AM, atorikoshi
>> wrote:
>> > Hi,
>> >
>> > I found below formula to compute selectivities, but
>> > I think the last Probability &
if (constr != NULL)
{
...
}
return false;
May be you should return false when constr == NULL (I prefer !constr, but
others may have different preferences.). That should save us one level of
indentation. At the end just return whatever predicate_implied_by() returns.
--
Bes
on as to why the observed behaviour is correct
one? Was there a commit which allowed startup process to be part of
pg_stat_activity but forgot to update the documentation or the current
behaviour is unintentional and probably needs to be fixed?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporatio
at for committer
> (ie, +1 for Ready for Committer).
That issue has not been addressed. The reason stated was that it would
make code complicated. But I have not had chance to look at how
complicated would be and assess myself whether that's worth the
trouble. There was another issue
Also, I don't see any discussion about my concern [3] about a parent
with child from multiple foreign servers with different FDWs. So, I am
not sure whether the patch really fixes the problem in its entirety.
[3]
https://www.postgresql.org/message-id/cafjfprfq1pkcjnqfvop_bpjfc7or3596nqvvfbgaidezqb4...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-z) and have it process all the
> WAL files that you've got on hand.
>
+1.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas wrote:
> On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat
> wrote:
>> Some more comments on the latest set of patches.
>>
>> In heap_drop_with_catalog(), we heap_open() the parent table to get the
>> default partitio
quot;, cannot
> add a new partition",
>
> This error message style seems novel to me. I'm not sure about the best
> message text here, but maybe: "cannot add new partition to table \"%s\"
> with default partition"
>
> Note that the comment applies to both
On Thu, Jun 15, 2017 at 2:30 PM, Amit Langote
wrote:
> On 2017/06/15 17:53, Ashutosh Bapat wrote:
>> On Thu, Jun 15, 2017 at 2:12 PM, Amit Langote wrote:
>>>> Both of the above comments are not related to the bug that is being fixed,
>>>> but
>>>> the
On Thu, Jun 15, 2017 at 2:12 PM, Amit Langote
wrote:
> Thanks for the review.
>
> On 2017/06/15 16:08, Ashutosh Bapat wrote:
>> On Thu, Jun 15, 2017 at 10:46 AM, Amit Langote wrote:
>>> If we end up having to perform the validation scan and the table being
>>> at
On Thu, Jun 15, 2017 at 10:46 AM, Amit Langote
wrote:
> Thanks for taking a look.
>
> On 2017/06/14 20:06, Ashutosh Bapat wrote:
>> On Wed, Jun 14, 2017 at 9:20 AM, Amit Langote
>> wrote:
>>>
>>> By the way, I mentioned an existing problem in one of the
NT check_a CHECK (a IS NOT NULL AND a = 6)
+);
+ALTER TABLE part_6 DROP c;
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
_is_check.
0003 addresses comments by Amit Langote.
In your original patch, if restrictinfo_is_check is true, we will call
operator_predicate_proof(), which does not handle anything other than
an operator expression. So, it's going to return false from that
function. Looking at the way argi
On Wed, Jun 14, 2017 at 10:21 AM, Ashutosh Bapat
wrote:
> On Tue, Jun 13, 2017 at 7:14 PM, Rahila Syed wrote:
>> I reviewed and tested
>> 0001-Dependency-between-partitioned-table-and-partition_v1.patch
>> It applies cleanly on master and make check passes.
>>
&g
TE_TYPE_DEPENDENCY isn't conveying the real sense.
But that's not a topic for this thread. I will start a separate a
thread.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
1-Dependency-between-partitioned-table-and-partition_v1.patch. Please
> find attached the v2 patch.
>
>
>
> On Tue, Jun 13, 2017 at 10:25 AM, Amit Langote
> wrote:
>>
>> Hi Ashutosh,
>>
>> On 2017/06/12 20:56, Ashutosh Bapat wrote:
>> > Hi,
&
I'll push my original patch and work up patches
> for the other couple of issues I found.
No objections, the patch is good to go as is. Sorry for high-jacking
this thread.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;>>> out for more of the same. I did a quick scan of the rewriter code
>>>>> (prompted by the recent similar omission for RLS on partitioned
>>>>> tables) and I didn't find any more problems there, but I haven't
>>>>> looked elsewhe
ables) and I didn't find any more problems there, but I haven't
>>> looked elsewhere yet.
>
> As he mentioned in his reply, Ashutosh's proposal to abstract away the
> relkind checks is interesting in this regard.
>
> On 2017/06/12 17:29, Ashutosh Bapat wrot
partition_bound() and get_partition_for_tuple(). Both of
those callers are calling it only in case of LIST partition. So,
having null_index uninitialized in PartitionBoundInfoData is not a
problem. But in general, we shouldn't leave a field uninitialized in
that structure, so +1 for the pat
101 - 200 of 973 matches
Mail list logo
