On Fri, Apr 15, 2016 at 9:39 PM, Robert Haas wrote:
> On Thu, Apr 14, 2016 at 7:49 AM, Ashutosh Bapat
> wrote:
> > BTW, I noticed that we are deparsing whole-row reference as ROW(list of
> > columns from local definition of foreign table), which has the same
> problem
>
onDescData as
{
int nparts;
PartitionInfo *partinfo; /* array of partition information structures. */
}
The new syntax allows CREATE TABLE to be specified as partition of an
already partitioned table. Is it possible to do the same for CREATE FOREIGN
TABLE? Or that's material for v2? Similarly for ATTACH PARTITION.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
y for ATTACH PARTITION.
3. PartitionKeyData contains KeyTypeCollInfo, whose contents can be
obtained by calling functions exprType, exprTypemod on partexprs. Why do we
need to store that information as a separate member?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
way, I look forward to working on this for 9.7.
>
> Thanks,
> 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
encapsulated in CASE
WHEN .. END expression. PFA patch with that fix included and also some
testcases for system columns as well as whole-row references.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/pos
On Thu, Apr 14, 2016 at 8:42 AM, Etsuro Fujita
wrote:
> On 2016/03/29 23:20, Ashutosh Bapat wrote:
>
>> I think the reason for that is in foreign_join_ok. This in that
>> function:
>>
>> wrongly pulls up remote_conds from joining relations in the FULL
make_tuple_from_result_row and
>> conversion_error_callback made by the postgres_fdw join pushdown patch.
>> What do you think about that?
>>
>
> I revised comments a little bit. Attached is an updated version of the
> patch. I think this issue should be fixed in adv
lar case that was reported, the bug triggered because of the way
conditions are handled for an inner join. For an inner join, all the
conditions in ON as well as WHERE clause are treated like they are part of
WHERE clause. This allows pushing down a join even if there are unpushable
join clauses.
me of planning should be fine since
change in tableoid between planning and execution will trigger plan cache
invalidation. I haven't tried this though.
Sorry for bringing this solution late to the table.
On Thu, Mar 24, 2016 at 3:04 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com&g
On Thu, Mar 24, 2016 at 9:31 AM, Etsuro Fujita
wrote:
> On 2016/03/23 13:44, Ashutosh Bapat wrote:
>
>> An FDW can choose not to use those functions, so I don't see a
>> connection between scan list having simple Vars and existence of those
>> functions (actually a
> > Thanks for the report and the testing. I have committed the patch.
>
>
Thanks.
> Cool, I have refreshed the wiki page for open items accordingly.
>
Thanks.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Mar 23, 2016 at 8:20 AM, Etsuro Fujita
wrote:
> On 2016/03/22 21:10, Ashutosh Bapat wrote:
>
>> On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> On 2016/03/22 14:54, Ashutosh Bapat wrote:
>>
On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita
wrote:
> On 2016/03/22 14:54, Ashutosh Bapat wrote:
>
>> On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> OK, I'll modify the patch so that the join is push
ns which can be used by FDWs, if they want, to return values
for those columns. Something like Datum
get_syscol_value(RelOptInfo/Relation, attno). The function will return
Datum 0 for most of the columns and table's OID for tableoid. My 0.02.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
add
pathkeys which will help merge joins. I have included the relevant tests
rewriting them to use local tables, so that the entire join is not pushed
down to the foreign server.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/contrib/postg
On Wed, Mar 16, 2016 at 10:22 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Mar 16, 2016 at 4:10 AM, Ashutosh Bapat <
> > ashutosh.ba...@enterprisedb.com> wrote:
> >> In 9.5, postgres_fdw allowed to prepare statements involving foreign
> >> table
t means those attributes won't be set while fetching the row from
the foreign server and will have garbage values in corresponding places. I
guess that would work.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
sh down of higher operations. It seems
very much possible after the upper pathification changes. We can not have a
query sent to the foreign server for a relation, when pushdown_safe is
false for that. Your patch does that for foreign base relation which try to
fetch system columns.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Mar 16, 2016 at 2:14 AM, Robert Haas wrote:
> On Tue, Mar 15, 2016 at 6:44 AM, Ashutosh Bapat
> wrote:
> > Here's patch which fixes the issue using Robert's idea.
>
> Please at least check your patches with 'git diff --check'
Thanks.
> befo
h sides have
> InvalidOid?
>
> Exactly. And we should make sure (possibly with a regression test)
> that postgres_fdw handles that case correctly - i.e. with the right
> error.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
ies that user mapping is meaningless to
it. Should we allow the user mapping to be created but ignore it or do not
allow it to be created? In the later case, what should happen to the
existing user mappings?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
wrote:
> Hi,
>
> On 2016/02/09 14:09, Ashutosh Bapat wrote:
>
>> Sorry, I was wrong. For public user mapping userid is 0 (InvalidOid),
>> which is returned as is in UserMapping object. I confused InvalidOid
>> with -1
;
Those look fine. Sorry for missing those in the commit and thanks for
providing a patch for the same.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ough, I think this would have been OK when pull_var_clause was being
written afresh. Now, that we have this API, I am not sure whether the
effort is worth the result.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Mar 9, 2016 at 9:22 PM, Robert Haas wrote:
> On Wed, Mar 9, 2016 at 2:23 AM, Ashutosh Bapat
> wrote:
> > [ new patch ]
>
> This looks OK to me. Committed!
>
>
Thanks.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
there will
be a single equivalence member A.c3 in the pathkeys and em_relids will
indicate only A. Hence instead of equal, (which used to be OK for single
relation join push-down) we have to use subset operation. We want an
equivalence members whose relids are subset of relids contained by gi
On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier
wrote:
> On Wed, Mar 2, 2016 at 7:04 PM, Rajkumar Raghuwanshi
> wrote:
> > On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat
> > wrote:
> >>
> >> Thanks Rajkumar for your report. Let me know if the
;
> create user mapping for db1 server db2_link_server options (user 'db2',
> password 'db2');
>
> --create a foreign table
> create foreign table fdw_sort_test (id integer, name varchar(50)) server
> db2_link_server;
>
> --run the below query and checkout th
ction just doesn't seem to fit into this section at
> all. It's really quite different from the others listed there. How
> about something like the attached instead?
Right. Mentioning the function in the description of relevant function
looks better and avoids some duplication.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
their right place.
On Wed, Feb 17, 2016 at 5:37 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi All,
> Now that we have join pushdown support in postgres_fdw, we can leverage
> the sort pushdown mechanism for base relations to work for pushed down
> joins as w
On Thu, Feb 18, 2016 at 3:48 PM, Etsuro Fujita
wrote:
> On 2016/02/16 16:40, Etsuro Fujita wrote:
>
>> On 2016/02/16 16:02, Ashutosh Bapat wrote:
>>
>>> On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita
>>> mailto:fujita.ets...@lab.ntt.co.jp>>
>>>
-id/CAFjFpRfeKHiCmwJ72p4=zvuzrqsau9tbfyw7vwr-5ppvrcb...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
pg_join_sort_pd.patch
Description: application/download
\set num_samples 10
\set query 'SELECT lt1.val, ft1.val, ft2.val FROM lt1 join (ft1 join ft2 on
return a void)
Thanks for pointing that out.
> and the paragraph about what it's for could do
> with some wordsmithing.
>
Any specific suggestions?
>
> A link from 54.2 to 54.3 which mentions it would be fine, of course.
>
Ok
PFA patch fixing those things.
--
Best
On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita wrote:
> On 2016/02/16 15:22, Ashutosh Bapat wrote:
>
>> During join planning, the planner tries multiple combinations of joining
>> relations, thus the same base or join relation can be part of multiple
>> of combinatio
:
> On 2016/02/15 21:33, Ashutosh Bapat wrote:
>
>> Here's patch with better way to fix it. I think while concatenating the
>> lists, we need to copy the lists being appended and in all the cases. If
>> we don't copy, a change in those lists can cause changes in the
s and thus lists of any higher level joins.
On Mon, Feb 15, 2016 at 1:10 PM, Etsuro Fujita
wrote:
> On 2016/02/10 4:16, Robert Haas wrote:
>
>> On Tue, Feb 9, 2016 at 8:39 AM, Ashutosh Bapat
>> wrote:
>>
>>> Thanks Jeevan for your review and comments. PFA the patc
, 2016 at 8:39 AM, Ashutosh Bapat
> > wrote:
> >> Thanks Jeevan for your review and comments. PFA the patch which fixes
> those.
> >
> > Committed with a couple more small adjustments.
>
> I'm getting a compiler warning which I think is coming from thi
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> 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
Yay, finally!
Thanks.
On Wed, Feb 10, 2016 at 12:46 AM, Robert Haas wrote:
> On Tue, Feb 9, 2016 at 8:39 AM, Ashutosh Bapat
> wrote:
> > Thanks Jeevan for your review and comments. PFA the patch which fixes
> those.
>
> Committed with a couple more small adjustments
Sorry, I was wrong. For public user mapping userid is 0 (InvalidOid), which
is returned as is in UserMapping object. I confused InvalidOid with -1.
Sorry for the confusion.
On Tue, Feb 9, 2016 at 10:21 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Sorry to come to this late.
>
nd userid.
>
> Pushed, thanks.
>
> regards, tom lane
>
>
> --
> 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,
A
t.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c
index fb72f45..7a2a67b 100644
--- a/contrib/postgres_fdw/deparse.c
+++ b/contrib/postgres_fdw/deparse.c
@@ -93,9 +93,10 @@ typedef str
IUC, all
of them output the same targetlist. We don't need to make sure that
targetlist match as long as we are using the targetlist passed in by
create_scan_plan(). Do you have a counter example?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Feb 4, 2016 at 4:30 AM, Robert Haas wrote:
> On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas wrote:
> > On Wed, Feb 3, 2016 at 12:08 PM, Ashutosh Bapat
> > wrote:
> >> PFA patches with naming conventions similar to previous ones.
> >> pg_fdw_core_v7.patch:
On Thu, Feb 4, 2016 at 3:28 PM, Etsuro Fujita
wrote:
> On 2016/02/04 17:58, Etsuro Fujita wrote:
>
>> On 2016/02/04 8:00, Robert Haas wrote:
>>
>>> On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas
>>> wrote:
>>>
>>>> On Wed, Feb 3, 2016 at 12:
rameterized join paths
would be closer to parameterized foreign paths (if we were to produce
those). Hence my statement. There is always a possibility that those two
costs are way too different, hence I have used phrase "possibly" there. I
could be wrong.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
fdw_outerpath
should be a local path set when paths for outerjoinpath->parent was being
created. Am I missing something?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ession tests added.
>
> Committed.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/contrib/postgres_fdw/postgres_f
On Tue, Feb 2, 2016 at 5:18 AM, Robert Haas wrote:
> On Mon, Feb 1, 2016 at 8:27 AM, Ashutosh Bapat
> wrote:
> > Here are patches rebased on recent commit
> > cc592c48c58d9c1920f8e2063756dcbcce79e4dd. Renamed original
> deparseSelectSql
> > as deparseSe
On Fri, Jan 29, 2016 at 2:05 PM, Etsuro Fujita
wrote:
> On 2016/01/29 1:26, Ashutosh Bapat wrote:
>
>> Here's an updated version of the previous patches, broken up like before
>>
>
> 2. pg_fdw_join_v3.patch: changes to postgres_fdw - more description below
>>
On Fri, Jan 29, 2016 at 9:51 AM, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 11:26 AM, Ashutosh Bapat
> wrote:
> > 2. pg_fdw_join_v3.patch: changes to postgres_fdw - more description below
>
> This patch no longer quite applies because of conflicts with one of
> your
u-vppq1d7ufsjaopbq+lgpxtchnuqfobjg2...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
pg_fdw_concache.patch.large
Description: Binary data
pg_fdw_concache.patch.short
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
ng oid (which will have invalid user id for
public user mapping) and used userid from that structure, we will get rid
of this problem.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Jan 21, 2016 at 3:03 AM, Robert Haas wrote:
> On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat
> wrote:
> > 2. pg_fdw_join_v2.patch: postgres_fdw changes for supporting join
> pushdown
>
> The very first hunk of this patch contains annoying whitespace
> changes
in_v2.patch, postgresBeginForeignScan() obtained user mapping
using GetUserMappingById() instead of the earlier way of fetching it by
userid and serverid. So even that change will remain, right?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
I missed the example plan cache revalidation patch in the previous mail.
Sorry. Here it is.
On Wed, Jan 20, 2016 at 7:20 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Wed, Jan 20, 2016 at 4:58 AM, Robert Haas
> wrote:
>
>> On Mon, Jan 18, 2016
On Wed, Jan 20, 2016 at 4:58 AM, Robert Haas wrote:
> On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat
> wrote:
> > Thanks Thom for bringing it to my notice quickly. Sorry for the same.
> >
> > Here are the patches.
> >
> > 1. pg_fdw_core_v2.patch: cha
9fOZ0dNNf9Z=gnyksb6wg...@mail.gmail.com
I will be working next on (in that order)
1. eval_plan_qual fix for foreign join. (Considered as a must-have for 9.6)
2. Pushing down ORDER BY clause along with join pushdown
3. Parameterization of foreign join paths (Given the complexity of the
feature this may not make it into 9.6)
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ps to get sorted
data from the foreign server. LIMIT pushdown is not supported yet, though.
>
> --
> Konstantin Knizhnik
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Thu, Jan 14, 2016 at 9:31 AM, Etsuro Fujita
wrote:
> On 2016/01/08 22:05, Ashutosh Bapat wrote:
>
>> In add_paths_to_joinrel(), the FDW specific hook GetForeignJoinPaths()
>> is called. This hook if implemented should add ForeignPaths for pushed
>> down joins. cre
/message-id/cafjfprdhgenohm0ab6gxz1evx_yoqkywukddzeb5vpzfbae...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 953aa62..bb1c058 100644
--- a/
erver level option is true or table
level option is true.
ANDing or ORing use_remote_estimate from the joining relations'
PgFdwRelationInfo looks cheaper than pulling it out of ForeignServer
structure.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Dec 24, 2015 at 8:32 AM, Michael Paquier
wrote:
> On Mon, Nov 9, 2015 at 8:55 PM, Ashutosh Bapat
> wrote:
> >
> >
> > On Sat, Nov 7, 2015 at 12:07 AM, Robert Haas
> wrote:
> >>
> >> On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat
> >&g
Thanks.
On Wed, Dec 23, 2015 at 12:24 AM, Robert Haas wrote:
> On Mon, Dec 21, 2015 at 6:34 AM, Ashutosh Bapat
> wrote:
> >> I went over this patch in some detail today and did a lot of cosmetic
> >> cleanup. The results are attached. I'm fairly happy with this
On Fri, Dec 18, 2015 at 6:39 PM, Albe Laurenz
wrote:
> Ashutosh Bapat wrote:
> > Costs for foreign queries are either obtained from the foreign server
> using EXPLAIN (if
> > use_remote_estimate is ON) otherwise they are cooked up locally based on
> the statistics availa
sing; EC can
not be associated with a query per say and EC's are always unique because
of canonicalisation. May be we should reword it as "Extract single EC for
ordering of query, if any, so we don't consider it again." Is that cryptic
as well?
--
Best Wishes,
Ashutosh Bapat
En
FF?
[1]
http://www.postgresql.org/message-id/CAFjFpRepSC2e3mZ1uYSopJD6R19fOZ0dNNf9Z=gnyksb6wg...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
uces by approx 9%. Again the deviation in execution reduces
heavily (almost by 75%). There is increase in planning time with the patch
owing to firing EXPLAIN on the foreign server.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
-- \set num_rows (1000*10
lly.
Comments/suggestions are welcome.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Fri, Dec 11, 2015 at 3:41 AM, Robert Haas wrote:
> On Wed, Dec 2, 2015 at 6:45 AM, Ashutosh Bapat
> wrote:
> > It's been a long time since last patch on this thread was posted. I have
> > started
> > to work on supporting join pushdown for postgres_fdw. Att
o get that fixed. Hopefully we won't
need that long to implement the hook in postgres_fdw, but that number says
something about the complexity of the feature.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Dec 3, 2015 at 12:36 PM, Etsuro Fujita
wrote:
> Hi Ashutosh,
>
> On 2015/12/02 20:45, Ashutosh Bapat wrote:
>
>> It's been a long time since last patch on this thread was posted. I have
>> started
>> to work on supporting join pushdown for postg
On Fri, Dec 4, 2015 at 10:58 AM, Amit Langote wrote:
> On 2015/12/03 21:26, Ashutosh Bapat wrote:
> > Session 1
> > postgres=# begin;
> > BEGIN
> > postgres=# update t1 set val = 2 where val2 = 1;
> > UPDATE 1
> >
> > Session 2
> > postgres=
val | val2 | val | val2
-+--+-+--
2 |1 | |
2 |1 | |
(2 rows)
It's confusing to see two rows from left join result when the table really
has only a single row. Is this behaviour expected?
On Thu, Dec 3, 2015 at 3:49 PM, Ashutosh Bapat <
from t1, lateral (select distinct val, val2 from t2 where t2.val =
t1.val) t2 for update of t1;
have same semantic and should give same results.
Is seeing different results expected behaviour?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
t;
> Thanks,
> Matvey Arye
> Iobeam, Inc.
>
>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/Postgres-FDW-optimizations-tp5875911.html
> Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
>
>
> --
> 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
thkeys used
for merge join. That routed through LIMIT node remains ordered. So, we
actually do not need ORDER BY t1.c1 clause in the above queries. Without
that clause, the tests will show difference output with and without patch.
I have changed the attached patch accordingly.
>
> Apa
On Thu, Nov 19, 2015 at 7:30 AM, Robert Haas wrote:
> On Tue, Nov 17, 2015 at 8:33 AM, Ashutosh Bapat
> wrote:
> >> Although I'm usually on the side of marking things as extern whenever
> >> we find it convenient, I'm nervous about doing that to
> >&g
say WHY the other way would
> be wrong.
There's no "other way" which is wrong. What's the other way you are talking
about?
Anway, I have updated the comment to be more readable.
> Then a few lines later, you have another comment which says
> the same thing again:
>
> +/*
>
on for a foreign table var. As said
upthread, different glibc implementations can cause collation ordering
mismatch, this patch will be susceptible to the same problem as
master/standby problem.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
5b3d5c1256de40051686f/$FILE/tdd99.pdf
>
>
>
> Sorry, may be I missed some message. but I have not received request from
> you to provide feedback concerning your patch.
>
>
See my mail on 31st August on hackers in the thread with subject
"Horizontal scalability/sharding&quo
On Sat, Nov 7, 2015 at 12:07 AM, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat
> wrote:
> > The previous patch would not compile on the latest HEAD. Here's updated
> > patch.
>
> Perhaps unsurprisingly, this doesn't apply any more. Bu
omments/suggestions are welcome.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index 0159bf5..ddb05f2 100644
--- a/contrib/postgres_fdw/expected/pos
On Tue, Nov 3, 2015 at 11:35 PM, Robert Haas wrote:
> On Fri, Oct 30, 2015 at 6:19 AM, Ashutosh Bapat
> wrote:
> > If there is a collate clause in the ORDER BY, the server crashes with
> > assertion
> > +Assert(loc_cxt.state == FDW_COLLATE_NONE ||
> &
expression since the subtree
it's examining might be part of an expression which does not use the
collation ultimately.
On Wed, Oct 28, 2015 at 11:51 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Tue, Oct 27, 2015 at 6:44 PM, FabrÃzio de Royes Mello <
> fabriziome
On Tue, Oct 27, 2015 at 6:44 PM, FabrÃzio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Tue, Oct 27, 2015 at 5:26 AM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
> >
> >
> >
> > On Fri, Oct 23, 2015 at 2:43 AM, Robert Ha
On Fri, Oct 23, 2015 at 2:43 AM, Robert Haas wrote:
> On Wed, Oct 21, 2015 at 5:23 AM, Ashutosh Bapat
> wrote:
> > Increasing the sorting cost factor (when use_remote_estimates = false)
> from
> > 1.1 to 1.2 makes the difference disappear.
> >
> > Since the s
On Mon, Oct 26, 2015 at 4:09 PM, Amit Kapila
wrote:
> On Mon, Oct 26, 2015 at 12:07 PM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
>
>>
>>
>> On Mon, Oct 26, 2015 at 10:19 AM, Amit Kapila
>> wrote:
>>>
>>>
>>>
and then do the in-place update in heap row.
>
>
In that case, readers would pay the penalty for constructing the row.
PostgreSQL will not incur the cost of reconstruction. Either writer or
reader is bound to pay penalty. If the user's load is reader heavy it makes
sense to use something like PG, else something like what is described above.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Here's patch with the regression fixed.
On Wed, Oct 21, 2015 at 2:53 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Fri, Oct 16, 2015 at 11:33 PM, Robert Haas
> wrote:
>
>> On Thu, Oct 15, 2015 at 6:28 AM, Ashutosh Bapat
>> wrote:
On Fri, Oct 16, 2015 at 11:33 PM, Robert Haas wrote:
> On Thu, Oct 15, 2015 at 6:28 AM, Ashutosh Bapat
> wrote:
> > Attached is the patch which takes care of above comments.
>
> I spent some time on this patch today. But it's still not right.
>
> I've at
On Thu, Oct 15, 2015 at 2:27 AM, Robert Haas wrote:
> On Wed, Oct 14, 2015 at 7:30 AM, Ashutosh Bapat
> wrote:
> > The patch uses a factor of 1.1 (10% increase) to multiple the startup and
> > total costs in fpinfo for unsorted data.
> >
> > This change has cause
PFA the patch with all the comments addressed.
On Tue, Oct 13, 2015 at 10:07 PM, Robert Haas wrote:
> On Tue, Oct 13, 2015 at 3:29 AM, Ashutosh Bapat
> wrote:
> >> - You consider pushing down ORDER BY if any prefix of the query
> >> pathkeys satisfy is_foreign_expr(
paths were getting eliminated by add_path().
I will take care of this one in the next version of patch.
> --
> Jeevan B Chalke
> Principal Software Engineer, Product Development
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
> On Tue, Oct 6, 2015 at 6:46 AM, Ashutosh Bapat
> wrote:
> > standard_qp_callback() sets root->query_pathkeys to pathkeys on which the
> > result of query_planner are expected be sorted upon (see the function for
> &g
ign scans.
3. In all the cases, the planning time increases owing to EXPLAIN queries
fired on the foreign server.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c
index 697de60..25d8
On Wed, Sep 2, 2015 at 2:02 AM, Robert Haas wrote:
> On Mon, Aug 31, 2015 at 8:01 AM, Ashutosh Bapat
> wrote:
> >> Thanks. It needs testing though to see if it really works as
> >> intended. Can you look into that?
> >
> > PFA the patch containing your cod
wn for above FDWs? Or FDW writers are facing problems
while implementing those hooks. In either case that should be reported on
hackers.
>
> The PostgreSQL wiki lists 85 foreign data wrappers, and only 18 of these
> have support for joins:
> https://wiki.postgresql.org/wiki/Foreign_data_wrappers
>
> Best,
> Ozgun
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
re aiming for write scalability.
>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
>
> --
> 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
On Sat, Aug 8, 2015 at 7:46 PM, Robert Haas wrote:
> On Wed, Aug 5, 2015 at 3:33 AM, Ashutosh Bapat
> wrote:
> > This idea looks good.
>
> Thanks. It needs testing though to see if it really works as
> intended. Can you look into that?
>
PFA the patch containing
701 - 800 of 973 matches
Mail list logo