ing only in the constraints checked
and the error message. It was manageable without partitioning and may
be it's still manageable, but it's certainly being pushed to the
limits. May be we should refactor error reporting code into a separate
function and call it in those three places.
--
Best Wish
7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgre
On Thu, Apr 6, 2017 at 6:37 AM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 2:42 AM, Ashutosh Bapat
> wrote:
>> Only inner join conditions have equivalence classes associated with
>> those. Outer join conditions create single element equivalence
>> classes. So, we can n
of
> postgres_fdw is using this stuff anyway, but it seems like a concern.
I had submitted a patch in [1]. We thought that that patch is good to
fix the issue on the backbranches. But it got berried in the thread.
If you think that's a feasible solution for backbranches, I will work
on the co
On Fri, Apr 7, 2017 at 9:02 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> While I agree that we can remove indesc->tdtypeid ==
>> outdesc->tdtypeid, I am not sure whether it should be replaced by
>> !indesc->tdhasoid && !outdesc->tdhasoid.
>
> No,
ential for biting third-party callers.
While I agree that we can remove indesc->tdtypeid ==
outdesc->tdtypeid, I am not sure whether it should be replaced by
!indesc->tdhasoid && !outdesc->tdhasoid. If that's required, it seems
to be a bug that needs to be fixed in earlier b
ll.
Probably we should also add an assertion there to make sure
ExecEvalConvertRowtype never gets same input and output types. If
that's the case, we don't need the copy as well.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailin
e working tree.
Use '--' to separate paths from revisions
--
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, Apr 6, 2017 at 8:51 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> In ExecEvalConvertRowtype(), if the input row doesn't require any
>> conversion, we simply return that row as is.
>
> Huh. That's been like that for a very long time.
>
>>
le, every constraint on the parent is applicable to the
child as well. So, we can apply constraint exclusion on partitioned
relation. Here's patch to do that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
pg_part_ce.patch
Description: Binary
k
tuple, it looks like copying is inevitable. But I am not sure if this
is the right fix or if there is any other way to avoid copying.
Comments are welcome.
[1]
https://www.postgresql.org/message-id/CAFjFpRfBipiEzP739PFDrzxrWG-UKThHj3tyHkwCeE2hDwP78A%40mail.gmail.com
--
Best Wishes,
Ash
On Wed, Apr 5, 2017 at 8:39 AM, Robert Haas wrote:
> On Tue, Apr 4, 2017 at 10:22 AM, Ashutosh Bapat
> wrote:
>> Yes, I agree. For an inner join, the partition key types need to "shrink"
>> and for outer join they need to be "widened". I don't k
eneficial to use more workers, then we should. Because otherwise you
> really can't use the resources available.
>
+1. I had expressed similar opinion earlier, but yours is better
articulated. Thanks.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Tue, Apr 4, 2017 at 2:31 PM, Etsuro Fujita
wrote:
>
> I rebased the patch also. Please find attached an updated version of the
> patch.
>
Thanks, marking this as "ready for committer".
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
oop().
>
Hmm, I see in match_unsorted_outer()
1254 case JOIN_RIGHT:
1255 case JOIN_FULL:
1256 nestjoinOK = false;
1257 useallclauses = true;
1258 break;
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Tue, Apr 4, 2017 at 2:01 AM, Andrew Gierth
wrote:
> >>>>> "Peter" == Peter Eisentraut
> writes:
>
> > On 4/3/17 02:44, Ashutosh Bapat wrote:
> >> [1] says that id.attribute is supported in stylesheets version
> >> 1.77.1. Do I nee
On Mon, Apr 3, 2017 at 8:36 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Recently my doc build has started failing with errors
> > runtime error: file stylesheet.xsl line 57 element call-template
> > The called template 'id.attribute' was not found.
>
On Mon, Apr 3, 2017 at 10:45 PM, Keith Fiske wrote:
>
> On Mon, Apr 3, 2017 at 5:13 AM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Mar 31, 2017 at 9:00 PM, Keith Fiske wrote:
>>
>>> I've gotten pg_p
n:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
poke with
> several core members at PGConf this year and they asked me to send an email
> to hackers making my case, so here it is!
>
>
I have not followed that mail thread closely, but it will help if you (if
interested) review/update the patch on thread and help the patch to get
into a committable state.
[1]
https://www.postgresql.org/message-id/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=aprcc_peo...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
laptop because of
recent changes in d63762452434a3a046e8c7d130d5a77c594176e4. So, I was not
able to check whether the patch builds or not. But I am hoping it builds
well.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
cft_doc_change.patch
Description: Bina
76245.
[1] says that id.attribute is supported in stylesheets version 1.77.1. Do I
need to update stylesheets version? How do I do it? Any help will be
appreciated.
[1] https://lists.oasis-open.org/archives/docbook-apps/201301/msg00040.html
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
=
>
> $ psql -d postgres -c "SELECT 1; SAVEPOINT sp"
> ERROR: SAVEPOINT can only be used in transaction blocks
>
>
> Regards
> Takayuki Tsunakawa
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
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
orced by the remote server. Similarly, a partition constraint
should also be enforced at the foreign server. Probably we should
update documentation of create foreign table to mention this. We have
updated ALTER TABLE ATTACH PARTITION documentation with a note on
foreign tables.
--
Best Wishes,
>> info into JoinPathExtraData when we don't give the FDW that chance.
>
>
> Done. Attached is a new version of the patch.
>
> Best regards,
> Etsuro Fujita
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql
v5zOtWtNPuiMYc01sb1SWjCOB1CT%3DuQ%40mail.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
s at all.
>>>>>
>>>>> This patch no longer applies.
>>>>
>>>> Rebased patch is attached.
>>>
>>> Oops, really attached this time,
>>
>> Committed with a bit of wordsmithing of the documentation.
>
> Thanks.
>
> Regards,
> Amit
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
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 Tue, Mar 28, 2017 at 10:24 PM, Robert Haas wrote:
> On Mon, Mar 27, 2017 at 8:36 AM, Ashutosh Bapat
> wrote:
>> I have gone through the patch, and it looks good to me. Here's the set
>> of patches with this patch included. Fixed the testcase failures.
>
On Wed, Mar 29, 2017 at 12:23 PM, Amit Langote
wrote:
> On 2017/03/29 15:20, Ashutosh Bapat wrote:
>> The prologue of set_append_rel_size() mentions
>>
>> * Note that in the inheritance case,
>> * the first member relation is actually the same table as is mentio
ot cover partitioning and so the sentence still holds. But I guess,
this needs some change so that we do not expect first member to be
same as partitioned table. I am not able to craft an elegant sentence
but how about something like attached?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporat
n such that is uses PartitionScheme, it could be used
for joins and probably when Jeevan's patch for partition-wise
aggregate [2] comes along, it can be used with grouping.
[1]
https://www.postgresql.org/message-id/CAFjFpRcMWwepj-Do1otxQ-GApGPSZ1FmH7YQvQTwzQOGczq_sw%40mail.gmail.com
[2] http://ww
On Fri, Mar 24, 2017 at 11:52 AM, Rushabh Lathia
wrote:
>
>
> On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat
> wrote:
>>
>> Hi,
>> In create_unique_path() there's comment
>> /*
>> * We must ensure path struct and subsidiary data are
On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat
wrote:
> Hi,
> In create_unique_path() there's comment
> /*
> * We must ensure path struct and subsidiary data are allocated in main
> * planning context; otherwise GEQO memory management causes trouble.
>
we can do that, I
will be happy.
In case, we have to include a stripped down version of
reparameterize_path_by_child(), with which I am fine too, we will need
to disable LATERAL joins, so that we don't end up with an error "could
not devise a query plan for the given query".
--
Best Wishes,
As
On Wed, Mar 22, 2017 at 6:32 PM, Robert Haas wrote:
> On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat
> wrote:
>> I have also completed reparameterize_path_by_child() for all the
>> required paths. There's no TODO there now. :) The function has grown
>> quite long no
>
> I tested the applied patch, it is fixing the reported issue.
Thanks for the confirmation Rafia. I have included the fix in the
latest set of patches.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-h
fo similar to mark_dummy_rel()?
--
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
rate_partition_wise_join_paths() which set cheapest paths for each
child-join. Because of this cheapest_*_paths are never set for those
rels, thus segfaulting in functions like sort_inner_and_outer() which
use those.
Here's patch fixing both the issues. Please let me know if it fixes
the issues
On Tue, Mar 21, 2017 at 2:19 PM, Amit Langote
wrote:
> On 2017/03/21 14:59, Ashutosh Bapat wrote:
>> When I run a query like below on a child-less table, the plan comes out to be
>>
>> explain verbose SELECT * FROM uprt1_l WHERE a = 1 AND a = 2;
>>
Thanks Rajkumar. Added those in the latest set of patches.
On Tue, Mar 21, 2017 at 3:52 PM, Rajkumar Raghuwanshi
wrote:
>> On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
>> wrote:
>
> I have created some test to cover partition wise joins with
> postgres_fdw, also verifie
1004 * reduces to a constant or pseudoconstant. (We must process them
1005 * separately to keep track of the security level of each qual.)
1006 */
Why do we want to create paths for the relation which we know is not
going to produce any result?
--
Best Wishes,
Ashutosh Ba
On Mon, Mar 20, 2017 at 10:26 PM, Robert Haas wrote:
> On Mon, Mar 20, 2017 at 12:52 PM, Ashutosh Bapat
> wrote:
>>> Hmm. I would kind of like to move the IS_JOIN_REL() and
>>> IS_OTHER_REL() stuff to the front of the series. In other words, I
>>> propose tha
e as the ones chosen for
partition-wise joins, we may need to fix the existing join cost
models.
--
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
before
multi-level partition-wise support, in case we see that multi-level
partition-wise join support can be committed. Does that sound good?
That way we save changing those macros twice.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-ha
On Sat, Mar 18, 2017 at 5:40 AM, Robert Haas wrote:
> On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat
> wrote:
>> This set of patches fixes both of those things.
>
> 0001 changes the purpose of a function and then 0007 renames it. It
> would be better to include the ren
>
> This patch applies cleanly and compiles at cccbdde.
>
> Ashutosh, do you know when you'll have a chance to review?
The scope of this work has expanded, since last time I reviewed and
marked it as RFC. Right now I am busy with partition-wise joins and do
not have sufficie
ndicated by pa_next_plan is finished, all the plans must have
finished. This should be true if we set pa_next_plan to 0 at the time of
initialization. Any worker picking up pa_next_plan will set it to the next
valid plan. So the next worker asking for plan should pick pa_next_plan and
set it t
On Thu, Mar 16, 2017 at 12:35 AM, Robert Haas wrote:
> On Wed, Mar 15, 2017 at 8:55 AM, Ashutosh Bapat
> wrote:
>> Sorry. That was added by my patch to refactor
>> set_append_rel_pathlist(). I have added a patch in the series to
>> remove that line.
>
> It'
On Thu, Mar 16, 2017 at 12:30 AM, Robert Haas wrote:
> On Wed, Mar 15, 2017 at 8:49 AM, Ashutosh Bapat
> wrote:
>>> Of course, that supposes that 0009 can manage to postpone creating
>>> non-sampled child joinrels until create_partition_join_plan(), which
>>>
means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
Thanks for pointing that out. I am able to reproduce the crash. I
think, we will need to teach it to add the indirect children as well.
code to be duplicated
in create_partition_join_plan() which is ugly. In an earlier version
of this patch I had that code, which I got rid of in the latest set of
patches. Between those two the first looks better.
>
> Incidentally, I committed 0002, 0003, and 0005 as a single commit with
&
?
>
Will it help to retain the partition hierarchy as inheritance
hierarchy and then collapse it while creating append paths. That will
be needed by partition-wise join, will be helpful in partition pruning
without using constraints and so on. So, may be could use that
infrastructure to simplify
Added this to 2017/7 commitfest to keep a track of it.
On Wed, Mar 8, 2017 at 3:39 PM, Amit Langote
wrote:
> On 2017/03/08 18:27, Ashutosh Bapat wrote:
>>>
>>> About the other statement you changed, I just realized that we should
>>> perhaps do one more thing.
Added this to 2017/07 commitfest.
On Fri, Mar 10, 2017 at 10:03 AM, Ashutosh Bapat
wrote:
>>>
>>> The new name merge_fdw_options() is shorter than the one I chose, but
>>> we are not exactly merging options for an upper relation since there
>>> isn't th
"
start-tag". The user mappings do not have name so the doc change was
slightly incorrect when it said "Do not throw an error if a user
mapping with the same name already exists.". I have corrected both
these things in the attached patch.
Other changes look good.
--
h I can guess, a bit, based on the commit message for 0007.
>
This is preparatory patch for 0015 which supports partition-wise join
for multi-level partitioned tables. We have discussed about
partition-wise join support for multi-level partitioned tables in [1].
We may decide to postpone patche
guarded just like rd_partdesc by
> relcache.c in face of invalidations (see keep_partkey logic in
> RelationClearRelation).
This suggestion looks good to me. Incorporated in the latest set of patches.
--
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
RC, we do that so that no other workers are assigned to it when
scanning the array of plans. But with the new scheme we don't need to
scan the non-parallel plans for when assigning plan to workers so -1
may not be needed. I may be wrong though.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corpor
On Fri, Mar 10, 2017 at 11:33 AM, Ashutosh Bapat
wrote:
>>
>> But as far as code is concerned, I think the two-list approach will
>> turn out to be less simple if we derive corresponding two different
>> arrays in AppendState node. Handling two different arrays during
&g
r the parallel ones when
a worker needs a plan to execute. We might eliminate the need for
special value -1 for num workers. You may separate those two kinds in
two different arrays or within the same array and remember the
smallest index of a parallel plan.
--
Best Wishes,
Ashutosh Bapat
Ente
On Thu, Mar 9, 2017 at 6:28 PM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 7:42 AM, Ashutosh Bapat
> wrote:
>>>
>>> +if (rel->partial_pathlist != NIL &&
>>> +(Path *) linitial(rel->partial_pathlist) == subpath)
>>
ations,
>> there's no need to have outerrel and innerrel in fpinfo of join.
>
> Looks like you forgot to update the comment on the Assert()
Yes and I also forgot to update the function prologue to refer to the
fpinfo_o/i instead of inner and outer relations. Attached patch
co
On Thu, Mar 9, 2017 at 11:44 PM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 1:19 AM, Ashutosh Bapat
> wrote:
>>>> At least we need to update the documentation.
>>>
>>> Got a proposal?
>>
>> How about something like attached?
>
> Committed w
hat we
allocate only one worker to that plan. I suggested that we use
path->parallel_workers for the same, but it seems that's not
guaranteed to be reliable. The reasons were discussed upthread. Is
there any way to infer whether we can allocate more than one workers
to a plan by looking
>
>> I didn't do anything about Ashutosh's comment that we could use ALTER
>> FOREIGN TABLE rather than ALTER TABLE someplace; that didn't seem
>> critical.
>
> Attached is a patch to fix that, just in case.
Thanks. Looks good to me.
--
Best Wishes,
A
>
>> At least we need to update the documentation.
>
> Got a proposal?
How about something like attached?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
attach_part_constraint_doc.patch
Description: Binary data
--
Sent via pgsql-hacke
On Thu, Mar 9, 2017 at 2:58 AM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> On Tue, Mar 7, 2017 at 9:23 PM, Stephen Frost wrote:
>> > I'm going through these with an eye towards committing them soon. I've
On Wed, Mar 8, 2017 at 7:00 PM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> On Mon, Mar 6, 2017 at 7:54 PM, Amos Bird wrote:
>> > Well, the prefix is used to differentiate other \d commands, like
>>
rver since it's not an FDW option per say.
It's better to keep that outside of this function. With your patch
fpinfo->server was being set twice for an upper relation.
>
> The changes from yours are mostly cosmetic, but I've also added a
> regression test too.
Tha
ne of \d output to \d+ to
better test partitioned tables without partitions in verbose and
non-verbose mode. Also, refactored the your code to have less number
of conditions. Please let me know if it looks good.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
nstead we might want to
add another column "access method" and specify the access method used
for that relation. But then only indexes seem to have access methods
per pg_class.h.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hac
On Tue, Mar 7, 2017 at 9:23 PM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> Here are patches for follwing
>> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
>> SUMMARY when ON prints planning tim
On Wed, Mar 8, 2017 at 7:36 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 7:14 AM, Ashutosh Bapat
> wrote:
>> Hi Amit,
>> Thanks for adding testcases. Overall the testcases look good.
>>
>> The testcase is using ALTER TABLE to modify foreign table schema.
>>
data, we can
refuse to attach a partition if corresponding check constraint is
absent on the foreign table being attached. A user will then be forced
to add that constraint if s/he is sure that the constraint will be
obeyed on the foreign server.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corpor
passed a RELKIND_PARTITIONED_TABLE
> relation. That's something to be fixed separately though. When we add
> autovacuum support for partitioned tables, we may want to add a new set of
> reloptions (new because partitioned tables still won't support all options
> returned by heap_reloptions()). Am I missing something?
>
> Thanks,
> Amit
--
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 Tue, Mar 7, 2017 at 9:33 AM, Etsuro Fujita
wrote:
> On 2017/03/06 21:22, Ashutosh Bapat wrote:
>>
>> On Mon, Mar 6, 2017 at 1:29 PM, David Rowley
>> wrote:
>>>
>>> On 6 March 2017 at 18:51, Etsuro Fujita
>>> wrote:
>>>>
>>
The function will copy the values of server level
options and derive values for table level options. We would add a note
there to keep this function in sync with apply_*_options(). I don't
think there's any better way to keep the options in sync for base
relations and join relations.
Here&
path.
--
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 Mon, Mar 6, 2017 at 11:12 AM, Ashutosh Bapat
wrote:
> On Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
>> On 6 March 2017 at 05:29, Ashutosh Bapat
>> wrote:
>>
>>> Just to confirm, you want the output to look like this
>>>>> \d+ t1
&g
>
> We can leave it for the committer to decide, maybe. Committers often
> rewrite surrounding comments to improve wording, correcting factual
> errors, etc.
>
Sure.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hacke
On Mon, Mar 6, 2017 at 1:26 PM, Amit Langote
wrote:
> On 2017/03/06 16:49, Ashutosh Bapat wrote:
>> On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote:
>>> On 2017/03/06 15:41, Michael Paquier wrote:
>>>> This comment is not completely correct. Children can be temp
nge the "temp
tables" to "temp table of other backends" in this patch.
>
> About has_child, the other option is to make the minimum length of
> appinfos list relkind-based, but the condition quickly becomes ugly. Do
> you have a suggestion?
>
+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 Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
> On 6 March 2017 at 05:29, Ashutosh Bapat
> wrote:
>
>> Just to confirm, you want the output to look like this
>>>> \d+ t1
>>>> Table "public.t1"
>&g
On Mon, Mar 6, 2017 at 10:55 AM, Simon Riggs wrote:
> On 6 March 2017 at 04:00, Ashutosh Bapat
> wrote:
>> On Mon, Mar 6, 2017 at 8:35 AM, Simon Riggs wrote:
>>> On 6 March 2017 at 00:51, Amit Langote
>>> wrote:
>>>> On 2017/03/05 16:20, Simon Riggs
On Sat, Mar 4, 2017 at 2:50 PM, Robert Haas wrote:
> On Thu, Mar 2, 2017 at 6:48 PM, Ashutosh Bapat
> wrote:
>> On Thu, Mar 2, 2017 at 6:06 PM, Rushabh Lathia
>> wrote:
>>> While reading through the cost_agg() I found that startup cost for the
>>> group aggr
ation to include is debatable, given that \d+ on that
partition is going to print it anyway.
--
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
t present.
AFAIK, catalogs have everything needed to fix this; it's just the
matter to using that information wherever it's 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
ery large number of partitions, MergeAppend on
in-memory sort wouldn't be efficient and might require a large
work_mem.
--
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, Mar 2, 2017 at 6:48 PM, Ashutosh Bapat
wrote:
> On Thu, Mar 2, 2017 at 6:06 PM, Rushabh Lathia
> wrote:
>> Hi,
>>
>> While reading through the cost_agg() I found that startup cost for the
>> group aggregate is not correctly assigned. Due to this expla
ucing the first aggregated row. startup_cost will be
input_startup_cost + cost to scan (total number of rows)/(number of
groups) rows + cost of transiting over those many rows. Total cost =
startup_cost + cost of scanning and transiting through the remaining
number of input rows.
--
Best Wishes,
A
hat change
> in the patch when I saw that it was consistent with current usage. Do we
> want to stick with the current usage where we treat the user name as the
> mapping name, or change it?
>
We should change existing usage and then commit the patch with new
usage. The new message be
catalogRelation,
> + parent_rel->rd_rel->relkind ==
> + RELKIND_PARTITIONED_TABLE);
>
> Thanks,
> Amit
>
>
I agree.
--
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
Updated 0001 patch with some more comments. Attaching all the patches
for quick access.
On Wed, Mar 1, 2017 at 2:26 PM, Ashutosh Bapat
wrote:
>>
>> 2. If the PartitionJoinPath emerges as the best path, we create paths
>> for each of the remaining child-joins. Then we
emory
saved. For a 5 way self-join of pg_class, the total memory consumed in
standard_planner() is 760K without patch and with patch it comes down
to 713K, saving 47K memory otherwise occupied by paths. It looks like
something useful even without partition-wise joins.
--
Best Wishes,
Ashutosh Bapat
tch with those changes and a few cosmetic tweaks attached.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
avoid-useless-partition-ops_v2.p
e p1;
> DROP TABLE
>
> \d+ p
>
> Partition key: LIST (a)
> Partitions: p2 FOR VALUES IN (2)
>
>> Please add a test for that so we can check automatically.
>
> OK, done.
Isn't list_range_parted multilevel partitioned table. It gets dropped
in the testcases. So, I guess, w
On Thu, Feb 23, 2017 at 1:38 PM, Amit Langote
wrote:
> On 2017/02/23 16:48, Ashutosh Bapat wrote:
>> On Thu, Feb 23, 2017 at 1:08 PM, Amit Langote wrote:
>>> @@ -996,10 +996,20 @@ inheritance_planner(PlannerInfo *root)
>>> /*
>>> +* Partit
On Thu, Feb 23, 2017 at 1:08 PM, Amit Langote
wrote:
> Thanks for the review.
>
> On 2017/02/23 15:44, Ashutosh Bapat wrote:
>> On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote:
>>> Rewrote that comment block as:
>>>
>>> *
>>> * I
On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote
wrote:
> Thanks for the review.
>
> On 2017/02/22 21:58, Ashutosh Bapat wrote:
>>>> Also we should add tests to make sure the scans on partitioned tables
>>>> without any partitions do not get into problems. PFA
I think this is ready for committer.
On Thu, Feb 23, 2017 at 12:02 PM, Amit Langote
wrote:
> On 2017/02/22 21:24, Ashutosh Bapat wrote:
>> On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote wrote:
>>> + /*
>>> +* Unlike inheritance children, partitio
301 - 400 of 973 matches
Mail list logo
