Re: [HACKERS] Aggregates push-down to partitions

postgresql.org/message-id/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1%2BS%2BvRuUQ%40mail.gmail.com You may want to review [2] and [3] as well. [2] https://www.postgresql.org/message-id/9666.1491295317@localhost [3] https://www.postgresql.org/message-id/CAM2+6=V64_xhstVHie0Rz=kpeqnljmzt_e314p0ja

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

is same. FWIW, we can order all clauses in largest set once and use that order every time. Albeit we will have to remember the order somewhere OR make the separator routine retain the order in the larger set, which I guess is true about all separator functions. -- Best Wishes, Ashutosh Bapat Enter

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

rs could also benefit > (having perhaps already ordered the qual clauses earlier). +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

Re: [HACKERS] dropping partitioned tables without CASCADE

partitions by their bounds somehow, DEFAULT partition listing would be tackled anyway. So, may be we should leave it outside the scope of this patch. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company From 398003b2d5f6b54e6cdd8542f653786987ef3bfe Mon Sep 17 00:00

Re: [HACKERS] dropping partitioned tables without CASCADE

ons as such and show the number of partitions. While your suggestion is a valid request, it's kind of beyond the scope of this patch. Someone might want to extend this request and say that partitions should be listed in the order of their bounds (I do feel that we should do some effort in tha

Re: [HACKERS] [POC] hash partitioning

, we may support ALTER TABLE ... PARTITION BY to change partition keys (albeit at huge cost of data movement). If we do that, we will have to remember this one-off instance of code which assumes that the partition keys are immutable. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Post

Re: [HACKERS] Account for cost and selectivity of HAVING quals

On Wed, Nov 1, 2017 at 8:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: >> On Wed, Nov 1, 2017 at 3:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> here's a patch to fix the planner so that eval costs

Re: [HACKERS] Account for cost and selectivity of HAVING quals

why can we ignore selectivity. Similarly for the changes in create_minmaxagg_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

Re: [HACKERS] Transactions involving multiple postgres foreign servers

ocess hangs in a connection to a foreign server etc. I am not sure that the complexity is worth the half-guarantee. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Fri, Oct 27, 2017 at 1:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Rowley <david.row...@2ndquadrant.com> writes: >> On 27 October 2017 at 01:44, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>> I think Antonin has a poi

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Fri, Oct 27, 2017 at 12:49 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 27 October 2017 at 01:44, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> I think Antonin has a point. The join processing may deem some base >> relations dummy (S

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

oin processing may deem some base relations dummy (See populate_joinrel_with_paths()). So an Append relation which had multiple child alive at the end of set_append_rel_size() might ultimately have only one child after partition-wise join has worked on it. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corpora

Re: [HACKERS] Transactions involving multiple postgres foreign servers

ive behaviour but I'd like to > share the current status of the patch. The patch includes regression > tests but not includes fully documentation. Any background worker, backend should be child of the postmaster, so we should not let a backend start a resolver process. It should be the jo

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

by_child() introduced for partition-wise join. -- 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

Re: [HACKERS] Re: Is anything preventing us from allowing write to foreign tables from standby?

uaranteed when foreign servers are written from a standby. I am not sure how easy would be to impose such a restriction and whether such a restriction would be practical. -- 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

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

in partitioned table. Sorry for not noticing this problem earlier. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company From eca9e03410b049bf79d767657ad4d90fb974d19c Mon Sep 17 00:00:00 2001 From: Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> Date: Mon, 16 Oct

Re: [HACKERS] [POC] hash partitioning

On Mon, Oct 16, 2017 at 2:36 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > > Probably we should move changes to partition_bounds_copy() in 0003 to > 0001, whose name suggests so. > We can't do this, hash partition strategy is introduced by 0002. Sorry for th

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 4:37 PM, amul sul <sula...@gmail.com> wrote: > On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Tue, Oct 10, 2017 at 3:32 PM, amul sul <sula...@gmail.com> wrote: >> >>>> +

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

r those comments are applicable in your case and also see how the callers handle the return values. -- 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 subscript

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

On Thu, Oct 12, 2017 at 9:46 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 11, 2017 at 7:08 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> Here's updated patch set based on the basic partition-wise join >> committed. The patchs

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Thu, Oct 12, 2017 at 10:49 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 11, 2017 at 10:43 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> You are suggesting that a dummy partitioned table be treated as an >> un-partitioned t

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Oct 11, 2017 at 7:47 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Oct 9, 2017 at 2:05 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Sat, Oct 7, 2017 at 1:04 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> Commit

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

ry ? > Every relation has a RelOptInfo associated with it. Predicates applicable to it are stored in this RelOptInfo as a list. For base relations (simple tables) it's in baserestrictinfo. The join predicates applicable are in joininfo. You can get RelOptInfo of a given simple table using find_base_rel(

Re: [HACKERS] [POC] hash partitioning

ughts? > > Okay, I think the dimension(dim) is also unfit here. Any suggestions? > I think natts is ok, since we are dealing with the number of attributes in the pack of datums; esp. when ndatums is already taken. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Databas

Re: [HACKERS] [POC] hash partitioning

fo(). >> > > Unless I am missing something, I don't think we should worry about parttyplen > because in the datumCopy() when the datatype is pass-by-value then typelen > is ignored. That's true, but it's ugly, passing typbyvalue of one type and len of other. -- Best Wishes, Ashuto

Re: [HACKERS] Partition-wise aggregation/grouping

f the > additional cost is consistent, but it's probably not worth being too > critical here. > This looks good to me. I think it should be a separate, yet very small patch. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-

Re: [HACKERS] Partition-wise aggregation/grouping

e should try to measure the actual time spent in Append node as a fraction of say time spent in child seq scans. That might give us a clue as to how Append processing can be charged in terms of costing. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company --

Re: [HACKERS] [POC] hash partitioning

you want here is the length of type of modulus and remainder. Is that correct? Probably we need some special handling wherever parttyplen and parttypbyval is used e.g. in call to partition_bounds_equal() from build_joinrel_partition_info(). -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation T

Re: [HACKERS] PoC: full merge join on comparison clause

l: http://www.postgrespro.com > The Russian Postgres Company > -- 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

Re: [HACKERS] separate serial_schedule useful?

gt;> used to enforce the rule. > > Concretely, how about the attached? (Obviously we'd have to fix > parallel_schedule before committing this.) > Thanks, this will help. May be we should set default to 20 instead of unlimited. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corpor

Re: [HACKERS] Proposal: Local indexes for partitioned table

command followed by ALTER INDEX abstract_index ATTACH PARTITION > concrete_index or something of that sort. That means you can't > absolutely count on the parent index to have all of the children it's > supposed to have but maybe that's OK. +1. How about CREATE INDEX ... PARTITION OF ..

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

e_join(). -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company From 4bf8ca38719aee730ed57a7f14522384b1ced7b0 Mon Sep 17 00:00:00 2001 From: Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> Date: Tue, 29 Aug 2017 12:37:14 +0530 Subject: [PATCH] Support parti

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

test to fail on prion. But I think, the bug could cause crash as well. The fix is to copy the relevant partitioning information from relcache into PartitionSchemeData and RelOptInfo. Here's a quick patch with that fix. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Com

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Oct 6, 2017 at 8:45 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Oct 6, 2017 at 8:40 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> Sorry. I sent a wrong file. Here's the real v37. > > Committed 0001-0006. I made some assorted co

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

tition key expressions from the OUTER side only. Consider a join > > I would join this with the previous sentence instead of repeating > strictly speaking: ...and thus the partition keys should include > partition key expressions from the OUTER side only. After that > sentence, I'd sk

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

;-" with "_" when syntax doesn't allow the first two. I am not against "partitionwise" but I don't see any real reason why we should move away from popular usage of this term. [1] https://users.cs.duke.edu/~shivnath/papers/sigmod295-herodotou.pdf -- 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

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Oct 4, 2017 at 9:01 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Sep 21, 2017 at 8:52 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Sep 21, 2017 at 8:21 AM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On Wed, Oct 4, 2017 at 5:32 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 4, 2017 at 6:40 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> Just like the local constraints on a foreign table are not ensured on >> remote table (unless user

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

omething less likely to duplicate other > tests. > There are tests for multi-level partitioned table in the file. They test whole partition hierarchy join, part of it being joined based on the quals. Search for -- -- multi-leveled partitions -- Have you looked at those? They test two-level par

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On Wed, Oct 4, 2017 at 3:45 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2017/10/03 18:16, Ashutosh Bapat wrote: >> >> Enforcing WCO constraints imposed by the local server on the row/DML >> being passed to the foreign server is fine, but trying to impo

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

dd. May be we should just leave this case as it is. I am comparing this case with the way we handle constraints on a foreign 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.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Transactions involving multiple postgres foreign servers

see what > else we want to do. > +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

Re: [HACKERS] PoC: full merge join on comparison clause

ure if that > approximation makes any sense, but this is the best I could think of. > > Style problems are fixed. > > Attached please find the new version of the patch that addresses all the > review comments except mergeopfamilies. > > The current commitfest is ending, but I'

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Sep 27, 2017 at 3:42 PM, Jeevan Chalke wrote: > Thanks Ashutosh for reviewing. > > Attached new patch-set with following changes: > > 1. Removed earlier 0007 and 0008 patches which were PoC for supporting > partial aggregation over fdw. I removed them as it

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

>> for partition-wise join and for partition pruning without constraint >> exclusion. >> >> Ashutosh Bapat, reviewed by Amit Langote and with quite a few changes, >> mostly cosmetic, by me. Additional review and testing of this patch >> series by Antonin Houska, Ami

Re: [HACKERS] Transactions involving multiple postgres foreign servers

t;> message back from the remote server. But even if that's not the >> scenario, I think we should assume that the DBA or some other system >> resolved it and therefore we don't need to do anything further. If we >> assume anything else, then we just go into an infinite error loop, &g

Re: [HACKERS] Partition-wise aggregation/grouping

EAD: 8edacab209957520423770851351ab4013cb0167 > Partition-wise Join patch-set version: v32 > > Thanks > > -- > Jeevan Chalke > Principal Software Engineer, Product Development > EnterpriseDB Corporation > The Enterprise PostgreSQL Company > > > > -- > Sent via

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Sep 15, 2017 at 5:29 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > >> >> Apart from these there is a regression case on a custom table, on head >> query completes in 20s and with this patch it takes 27s. Please find >> the attached

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

, every query improves when the tables are partitioned. Am I interpreting the results correctly? There may be some other way of partitioning, which may give better results, but I think what we have now shows the importance of partitioning in case of very large data e.g. scale 300 TPCH. --

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

parallel query works, but here's my analysis so far. I will continue investigating further. Any clues would be helpful. -- 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

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

bounds. This patch may avoid MergeAppend if the sort keys match partition keys by creating an Append path by picking sorted paths from partition RelOptInfos in order. You may use slightly modified version of add_paths_to_append_rel(). -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 19, 2017 at 3:17 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >> >>>> - I'm not entirely sure whether maintaining partexprs and >>>> nullable_partexprs is the right design. If I understand correctly, >>>> whether o

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

this. May be there's some faster way by looking at the lines that are covered by B but not A. BTW, I checked those lines to see if there could be any bug there. But I don't see what could go wrong with those lines. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Com

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

gt;Output: e.str1, e.str2, e.str3 >Remote SQL: SELECT str1, str2, str3 FROM > public.table_with_en_us_utf8_encoding WHERE ((str4 = '2'::text)) > Planning time: 0.153 ms > Execution time: 156.557 ms > (13 rows) > > In this case, both tables use same collation while comparing the rows, so result is different from the merge join result. Hash join executed on local server and the same executed on foreign server (by importing local table to the foreign server) would also differ. -- 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

Re: [HACKERS] PoC: full merge join on comparison clause

lly do not add {} around a single statement block. -- 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

Re: [HACKERS] postgres_fdw bug in 9.6

On Tue, Sep 5, 2017 at 1:10 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > > > I think Tom is reviewing this patch [1]. > I am marking this as ready for committer as I don't have any new comments and possibly other reviewers have also done reviewing it. -- Best Wish

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Sat, Sep 16, 2017 at 2:53 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 15, 2017 at 6:11 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> Thanks a lot Robert. >> >> Here are rebased patches. > > I didn't get quite as m

[HACKERS] Re: [COMMITTERS] pgsql: Expand partitioned table RTEs level by level, without flattening

re either "base" relations or "other" relations. This isn't true. The array can contain "dead" relations as well. I have removed the assertion and instead fixed the code to skip anything which is not "base" or "other member rel".

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

7tKbCLEGK3u5UWdDNQoN=eyfb7ieg5d0d1p...@mail.gmail.com [3] https://www.postgresql.org/message-id/cafjfprejksdcfaeuzjgd79hoetzpz5bkdxljgxr7qznrxx+...@mail.gmail.com -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hacker

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

rry for jumping back and forth. > > Alright, done. Thanks for reviewing. > LGTM. The patch applies cleanly on the current HEAD, compiles (small bit in regress.c requires compilation), and make check passes. Marking this as "ready for committer". -- Best Wishes, Ashutosh Bapat Enter

Re: [HACKERS] Log LDAP "diagnostic messages"?

On Wed, Sep 13, 2017 at 6:58 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Tue, Sep 12, 2017 at 11:23 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Wed, Aug 16, 2017 at 11:13 AM, Ashutosh Bapat >> <ashutosh.ba...@enterprise

Re: [HACKERS] <> join selectivity estimate question

On Thu, Sep 14, 2017 at 4:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@enterprisedb.com> writes: >> On Wed, Sep 6, 2017 at 11:14 PM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>> I added some "stab

Re: [HACKERS] <> join selectivity estimate question

On Thu, Sep 14, 2017 at 4:19 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Sep 6, 2017 at 11:14 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro >> <thomas.mu...@enterprisedb

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Sep 13, 2017 at 12:51 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Sep 13, 2017 at 12:39 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Sep 12, 2017 at 3:46 AM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >&

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Wed, Sep 13, 2017 at 1:27 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/13 16:42, Ashutosh Bapat wrote: >> On Wed, Sep 13, 2017 at 7:49 AM, Amit Langote wrote: >>> In the attached updated patch, I created separate .source files in >>>

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Wed, Sep 13, 2017 at 7:49 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/12 20:17, Ashutosh Bapat wrote: >> On Tue, Sep 12, 2017 at 2:27 PM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> Thanks Ashutosh for taking a look

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

hbj85bOmvJwY5fg%40mail.gmail.com > > All the TPCH results are posted in the same above mail thread. Can you please check if the attached patch fixes the issue. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company commit 203b3083318e9da41ad614a2ccec532025877c3b Autho

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Sep 13, 2017 at 11:29 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/12 19:56, Ashutosh Bapat wrote: >> I think the code here expects the original parent_rte and not the one >> we set around line 1169. >> >> This isn't a bug right now,

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

it Langote agrees with this. It kind of makes the assertion lame but keeps the code sane. What do you think? [1] https://www.postgresql.org/message-id/d2f1cdcb-ebb4-76c5-e471-79348ca5d...@lab.ntt.co.jp [2] https://www.postgresql.org/message-id/CAFjFpRfJ3GRRmmOugaMA-q4i=se5p6yjz_c6a6hdrdqqtgx...@mai

Re: [HACKERS] Constraint exclusion for partitioned tables

ed CPU cycles on one run of constraint exclusion. The difference between the time spent in the two scenarios increases with the number of partitions. Practically, users will have a handful partitions rather than a couple and thus running overhead of running constraint exclusion on partitioned table would be justified given the time it will save when CE succeeds. -- 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

Re: [HACKERS] dropping partitioned tables without CASCADE

>> Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks >> good to me too. > > Patch needed to be rebased after the default partitions patch went in, so > done. Per build status on http://commitfest.cputube.org :) > > Thanks, > Amit -- Best

Re: [HACKERS] Log LDAP "diagnostic messages"?

The patch needs to address some comments in the previous mails, so marking it as "waiting for author". On Wed, Aug 16, 2017 at 11:13 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Aug 16, 2017 at 8:44 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com&

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Tue, Sep 12, 2017 at 2:27 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Thanks Ashutosh for taking a look at this. > > On 2017/09/05 21:16, Ashutosh Bapat wrote: >> The patch needs a rebase. > > Attached rebased patch. Thanks for rebased patch. W

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 2:35 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/12 17:53, Ashutosh Bapat wrote: >> On Tue, Sep 12, 2017 at 1:42 PM, Amit Langote wrote: >>> So, we can remove partitioned_rels from (Merge)AppendPath and >>&g

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

lMarkTypes */ parentrc->allMarkTypes |= childrc->allMarkTypes; } so that we push allMarkTypes up the hierarchy. I like the second way, since every intermediate parent records allMarkTypes of its descendants. Thoughts? -- Best Wishes, Ashutosh Bapat EnterpriseDB Corpo

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 1:42 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/12 16:55, Ashutosh Bapat wrote: >> On Tue, Sep 12, 2017 at 1:16 PM, Amit Langote wrote: >>> So I looked at this a bit closely and came to the conclusion that we may >>

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 1:16 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/11 21:07, Ashutosh Bapat wrote: >> On Mon, Sep 11, 2017 at 5:19 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Mon, Sep 11, 2017 at 6:45 AM, Ashutosh Bapat >&g

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 7:31 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/11 19:45, Ashutosh Bapat wrote: >> On Mon, Sep 11, 2017 at 12:16 PM, Amit Langote wrote: >>> IMHO, we should make it the responsibility of the future patch to set a >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 5:19 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Sep 11, 2017 at 6:45 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> So, all partitioned partitions are getting locked correctly. Am I >> missing somethin

Re: [HACKERS] Automatic testing of patches in commit fest

wants to spam pgsql-hackers@ > with automatic messages to often. I believe that sending such messages > once a day would be enough. > > Unless there are any objections to give this idea a try I'm willing to > write and host a corresponding script. > +1 that would help. -- Best Wishe

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 2:16 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/11 16:23, Ashutosh Bapat wrote: >> On Sat, Sep 9, 2017 at 6:28 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> I'm a bit suspicious about the fact that there are no

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Sep 11, 2017 at 12:16 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/09 2:38, Ashutosh Bapat wrote: >> On Fri, Sep 8, 2017 at 11:17 AM, Amit Langote wrote: >>> I updated the patch to include just those changes. I'm not sure about >>&

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Sep 8, 2017 at 7:04 PM, Antonin Houska <a...@cybertec.at> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > >> On Thu, Aug 17, 2017 at 8:52 PM, Antonin Houska <a...@cybertec.at> wrote: >> > Antonin Houska <a...@cyb

Re: [HACKERS] [POC] hash partitioning

ning syntax, there can be "holes" in partitions. Default partition would help plug those holes. -- 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

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

On Thu, Sep 7, 2017 at 7:34 PM, Antonin Houska <a...@cybertec.at> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > >> I have fixed the issues which were marked as TODOs in the attached >> patches. Also, I have included your test change patch in my

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Sat, Sep 9, 2017 at 6:28 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 8, 2017 at 1:38 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >>> I also confirmed that the partition-pruning patch set works fine with this >>> patch

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Sep 8, 2017 at 12:34 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Sep 5, 2017 at 7:01 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> accumulate_append_subpath() is executed for every path instead of >> every relation, so changing

Re: [HACKERS] Adding support for Default partition in partitioning

s_bound() is called only from DefineRelation(), > and not for alter command. I am not really sure how can we use > work queue for create command. No, we shouldn't use work queue for CREATE command. We should extract the common code into a function to be called from check_default_allows_bound() a

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Thu, Sep 7, 2017 at 4:32 PM, Antonin Houska <a...@cybertec.at> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > >> On Fri, Sep 1, 2017 at 6:05 PM, Antonin Houska <a...@cybertec.at> wrote: >> > >> > >> > >> > *

Re: [HACKERS] WIP: Aggregation push-down

he aggregates. 2. Following query throws error with these patches, but not without the patches. explain verbose select sum(t1.a + t2.a) from t1, t2, t2 t3 where t1.a = t2.a group by t2.a, t1.a; ERROR: ORDER/GROUP BY expression not found in targetlist [1] https://www.postgresql.org/message-id/CA

Re: [HACKERS] <> join selectivity estimate question

chines and runs. Please let me know if those look good to you. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c index 23e5526..4c1bae6 100644 --- a/src/backend/utils/adt/selfuncs.

Re: [HACKERS] dropping partitioned tables without CASCADE

s" was to let know that it's a partitioned table. So can you > directly > add the "is partitioned" in place of "has partitions"? > > Did those change in the attached patch and update regression expected > output. > Looks better. > Also run pgindent

Re: [HACKERS] paths in partitions of a dummy partitioned table

On Fri, Aug 25, 2017 at 10:46 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the >> partition relati

Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately in planner.c

On Wed, Sep 6, 2017 at 1:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: >> On Tue, Sep 5, 2017 at 4:02 PM, Jeevan Chalke >> <jeevan.cha...@enterprisedb.com> wrote: >>> Attached patch for replacing li

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

gt;>> WRAPPER). >> >> Thank you for creating the patch. I only see one small oversight, which is >> the >> successful case of ALTER FOREIGN DATA WRAPPER ... HANDLER ... is still >> not tested. I added one line for that in the attached modification of your >>

Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately in planner.c

his commitfest entry as "ready for committer". From 25ae53d7f72a54a03ec90206c7e5579a562a121c Mon Sep 17 00:00:00 2001 From: Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> Date: Tue, 5 Sep 2017 16:50:58 +0530 Subject: [PATCH 1/2] Use lfirst_node() instead of lfirst() wherever suitable in planner.c Ashutosh Bapat,

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 5, 2017 at 1:16 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/05 15:43, Ashutosh Bapat wrote: >> Ok. Can you please answer my previous questions? >> >> AFAIU, the list contained RTIs of the relations, which didnt' have >> cor

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 5, 2017 at 12:06 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/05 15:30, Ashutosh Bapat wrote: >> Those changes are already part of my updated 0001 patch. Aren't they? >> May be you should just review those and see if those are suitable fo

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

the above described change in the partition-pruning > patch, because the other code in that patch relies on the same and I know > Ashuotsh has wanted that for a long time. :) Those changes are already part of my updated 0001 patch. Aren't they? May be you should just review those and see if t

Re: [HACKERS] dropping partitioned tables without CASCADE

ability. I think the > original is fine. > We have used this style in the "else" case of if (!verbose). So, I just copied it. I have removed that change in the attached patch. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company From c0a153f0535c4d1d

  1   2   3   4   5   6   7   8   9   10   >