On Thu, Jan 7, 2016 at 4:05 AM, Ashutosh Bapat
wrote:
> In get_useful_ecs_for_relation(), while checking whether to use left or
> right argument of a mergejoinable operator, the arguments to bms_is_subset()
> are passed in reverse order. bms_is_subset() checks whether the first
> argument in subse
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
> >> version, but let me know w
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
>> version, but let me know what you think. Of course, feedback from
>> others is more than welcome al
>
> 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
> version, but let me know what you think. Of course, feedback from
> others is more than welcome also.
>
>
Attached patch with some cosmetic changes (listed
On Sat, Dec 19, 2015 at 2:17 AM, Robert Haas wrote:
> On Thu, Dec 17, 2015 at 3:32 AM, Ashutosh Bapat
> wrote:
> > On Wed, Dec 9, 2015 at 12:14 AM, Robert Haas
> wrote:
> >> On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia <
> rushabh.lat...@gmail.com>
> >> wrote:
> >> > Thanks Ashutosh.
> >> >
>
On Thu, Dec 17, 2015 at 3:32 AM, Ashutosh Bapat
wrote:
> On Wed, Dec 9, 2015 at 12:14 AM, Robert Haas wrote:
>> On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia
>> wrote:
>> > Thanks Ashutosh.
>> >
>> > Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
>> > looks good to me.
>>
>> Thi
On Wed, Dec 9, 2015 at 12:14 AM, Robert Haas wrote:
> On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia
> wrote:
> > Thanks Ashutosh.
> >
> > Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
> > looks good to me.
>
> This patch needs a rebase.
>
Done.
>
> It's not going to work to
On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia wrote:
> Thanks Ashutosh.
>
> Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
> looks good to me.
This patch needs a rebase.
It's not going to work to say this is a patch proposed for commit when
it's still got a TODO comment in it th
Thanks Ashutosh.
Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
looks good to me.
On Fri, Nov 27, 2015 at 3:02 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Thanks Rushabh for your review and comments.
>
> On Thu, Nov 26, 2015 at 5:39 PM, Rushabh Lathia
> wrote
Thanks Rushabh for your review and comments.
On Thu, Nov 26, 2015 at 5:39 PM, Rushabh Lathia
wrote:
> Hi Ashutosh,
>
> I reviewed your latest version of patch and over all the implementation
> and other details look good to me.
>
> Here are few cosmetic issues which I found:
>
> 1) Patch not get
Hi Ashutosh,
I reviewed your latest version of patch and over all the implementation
and other details look good to me.
Here are few cosmetic issues which I found:
1) Patch not getting applied cleanly - white space warning
2)
-List *usable_pathkeys = NIL;
+List*useful_pat
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
> >> make_canonical_pathkey(), because it has side
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
>> make_canonical_pathkey(), because it has side effects. Searching the
>> list of canonical pathkeys for the o
Thanks Robert for your comments. Please see my replies inlined. Updated
patch is attached.
On Fri, Nov 6, 2015 at 10:02 PM, Robert Haas wrote:
>
> I think this approach is generally reasonable, but I suggested parts
> of it, so may be biased. I would be interested in hearing the
> opinions of o
On 16 November 2015 at 17:47, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> collations arising from a foreign table's var are considered to be safer
> (FDW_COLLATE_SAFE) to push down to the foreign server , since they are
> either local default collation or are assumed to be same o
On Mon, Nov 9, 2015 at 9:39 PM, Robert Haas wrote:
> On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner wrote:
> > Has anyone taken a close look at what happens if the two sides of
> > the merge join have different implementations of the same collation
> > name? Is there anything we should do to de
On 2015/11/10 0:56, Robert Haas wrote:
> On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker
> wrote:
>> Sorry to barge in late, but I was wondering if what we've learned with this
>> patch can be applied to the case of asserting a sort order on a query
>> returning from dblink().
>
> Nope.
>
> Sorr
On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner wrote:
> Has anyone taken a close look at what happens if the two sides of
> the merge join have different implementations of the same collation
> name? Is there anything we should do to defend against the
> problem?
The issue of FDWs vs. collations
On Sat, Nov 7, 2015 at 5:42 PM, Greg Stark wrote:
> On Fri, Nov 6, 2015 at 4:54 AM, Ashutosh Bapat
> wrote:
>> PFA patch to get data sorted from the foreign server (postgres_fdw)
>> according to the pathkeys useful for merge join.
>
> An idle thought. There are going to be a lot of cases where di
On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker wrote:
> Sorry to barge in late, but I was wondering if what we've learned with this
> patch can be applied to the case of asserting a sort order on a query
> returning from dblink().
Nope.
Sorry to the bearer of bad news, but that would be a differ
On Fri, Nov 6, 2015 at 4:54 AM, Ashutosh Bapat
wrote:
> PFA patch to get data sorted from the foreign server (postgres_fdw)
> according to the pathkeys useful for merge join.
An idle thought. There are going to be a lot of cases where different
software systems actually disagree about collation
On Fri, Nov 6, 2015 at 11:32 AM, Robert Haas wrote:
> On Thu, Nov 5, 2015 at 11:54 PM, Ashutosh Bapat
> wrote:
> > Hi All,
> > PFA patch to get data sorted from the foreign server (postgres_fdw)
> > according to the pathkeys useful for merge join.
> >
> > For a given base relation (extendable to
On Friday, November 6, 2015 10:32 AM, Robert Haas wrote:
> I think this approach is generally reasonable, but I suggested
> parts of it, so may be biased. I would be interested in hearing
> the opinions of others.
Has anyone taken a close look at what happens if the two sides of
the merge join
On Thu, Nov 5, 2015 at 11:54 PM, Ashutosh Bapat
wrote:
> Hi All,
> PFA patch to get data sorted from the foreign server (postgres_fdw)
> according to the pathkeys useful for merge join.
>
> For a given base relation (extendable to join when that becomes available in
> postgres_fdw), the patch trie
Hi All,
PFA patch to get data sorted from the foreign server (postgres_fdw)
according to the pathkeys useful for merge join.
For a given base relation (extendable to join when that becomes available
in postgres_fdw), the patch tries to find merge joinable clauses. It then
adds paths with pathkeys
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 ||
> > +loc_cxt.state == FDW_COLLAT
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 ||
> +loc_cxt.state == FDW_COLLATE_SAFE);
>
>
> The assertion is fine as long as is_foreign_expr()
If there is a collate clause in the ORDER BY, the server crashes with
assertion
+Assert(loc_cxt.state == FDW_COLLATE_NONE ||
+loc_cxt.state == FDW_COLLATE_SAFE);
The assertion is fine as long as is_foreign_expr() tests only boolean
expressions (appearing in quals). This patch uses
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 Haas
> wrote:
> >>
> >> On Wed, Oct 21, 2015 at 5:23
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 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
>>
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 startup costs for postgres_fdw are lar
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 startup costs for postgres_fdw are large portion of total cost,
> extra 10% of rest of the cost is compara
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:
>> > Attached is the patch which takes ca
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 attached a new version which fixes a seriou
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 attached a new version which fixes a serious problem with your
last version - having postgresGetForeignPaths d
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 caused the plans for few queries in th
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 caused the plans for few queries in the test postgres_fdw to
> change. There is ORDER BY and LIMIT claus
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(), but that doesn't seem righ
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(), but that doesn't seem right to me.
>> If the user says SELECT * FROM remotetab ORDER BY a, unsafe(a),
>> ordering the result set by a doe
On Tue, Oct 13, 2015 at 1:48 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
> On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
>>
>>>
>>> In the interest of full disclosure, I asked Ashutosh to work on this
>>> patch and have discussed the design with him several times. I believe
> On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
>
>>
>> In the interest of full disclosure, I asked Ashutosh to work on this
>> patch and have discussed the design with him several times. I believe
>> that this is a good direction for PostgreSQL to be going. It's
>> trivially easy right now
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
> > more details). The patch ch
On Thu, Oct 8, 2015 at 3:04 PM, Jeremy Harris wrote:
> That depends how often the additional columns affect the sorted
> order, if the sort method takes advantage of sorted input.
What I'm saying is - ours doesn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
On 08/10/15 17:09, Robert Haas wrote:
> - You consider pushing down ORDER BY if any prefix of the query
> pathkeys satisfy is_foreign_expr(), but that doesn't seem right to me.
> If the user says SELECT * FROM remotetab ORDER BY a, unsafe(a),
> ordering the result set by a doesn't help us much. We
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
> more details). The patch checks if any prefix of these pathkeys can be
> entirely evaluate
Hi All,
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
more details). The patch checks if any prefix of these pathkeys can be
entirely evaluated using the foreign relation and at the foreign server
46 matches
Mail list logo