Re: [Postgres-xc-developers] SRF not working ?

[Ashutosh B. <ash...@en...>]

On Fri, Jul 5, 2013 at 10:03 AM, Pavan Deolasee <pav...@gm...>wrote:

>
>
>
> On Fri, Jul 5, 2013 at 9:53 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>>
>>
>>
>> On Thu, Jul 4, 2013 at 6:50 PM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>>
>>>
>>>
>> I don't agree that it's because of immutability. It has more to do with
>> the VALUES_RTE in INSERT statement. Any INSERT statement that is inserting
>> more than one value in the distributed table can not be FQSed. In case
>> there are more than one value being INSERTED through an INSERT statement,
>> there are two RTEs in the query, one for the relation where INSERT is
>> happening, and other for the values. So, I had implemented a simple rule in
>> FQS shippability - if there are more than one RTEs in INSERT statement, do
>> not FQS it. But I am unable to locate this rule now. Looks like while
>> implementing something else, the rule has disappeared. And, since we do not
>> have test for it, we didn't notice it.
>>
>>
>
>
> You mean this code in pgxcship.c ?
>
>  905
>  906             /* PGXCTODO: It should be possible to look at the Query
> and find out
>  907              * whether it can be completely evaluated on the Datanode
> just like SELECT
>  908              * queries. But we need to be careful while finding out
> the Datanodes to
>  909              * execute the query on, esp. for the result relations.
> If one happens to
>  910              * remove/change this restriction, make sure you change
>  911              * pgxc_FQS_get_relation_nodes appropriately.
>  912              * For now DMLs with single rtable entry are candidates
> for FQS
>  913              */
>  914             if (query->commandType != CMD_SELECT &&
> list_length(query->rtable) > 1)
>  915                 pgxc_set_shippability_reason(sc_context,
> SS_UNSUPPORTED_EXPR);
>
>
Ah, right. I was searching for CMD_INSERT so couldn't locate it. Yes, this
is stronger and better condition not to FQS any DML with more than one RTE.
I am not sure why it doesn't obey VALUES generate_series()? May it doesn't
show up as an RTE.


> BTW, I looked at the regression and I spotted at least one test case that
> use generate_series() to insert data in a distributed table but still does
> not fail. Its so because the test case uses a subquery to fire the insert.
> So a workaround to the failing query is:
>
> INSERT INTO testtbl SELECT generate_series(1,10000), 'foo';
>
> Thanks,
> Pavan
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Postgres Database Company