You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When working with data having vertice property count in excess of 100 Postgres functions exhibit build - in limit of 100 arguments.
Examples:
function agtype_build_map treats each parameter as separate, map field name and map field value, hence, it limits input to 50 fields / call. To scale number of fields it can handle one has to continuously invoke constructs such as
agtype_add(
CypherInputParam_Var
, agtype_build_map(
/* 54 / field_name_54, field_value_54
/ 55 */ field_name_55, field_value_55
....
similarly when CREATE invoked subsequently in the context of call to cypher function and CypherInputParam_Var as an input parameter to overcome per call limit of parameters/properties requires to initially create subset of 50 fields and subsequently call constructs such as
CREATE (v:<vertice_name>
{... properties 1,2,3 ...
})
SET v += { properties 51... 100}
SET v += { properties 101... 150}
....
This limitation is grandfathered from functions servicing postgresql function check when using default build, as per Appendix K. PostgreSQL Limits document:
function arguments | 100 | can be increased by recompiling PostgreSQL
However, I am not 100% convinced that custom compilation of Postgres is the right approach in this case.
In an ideal world it would be nice if Age used under the hood an limit compatible with limit of Age, which I believe is 65,535 properties per vertice ( please correct me if I am wrong ).
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
@MironAtHome I can try to look into this tomorrow, time permitting. I recall something, somewhere, about this limit and creating a workaround. But, it's been a while.
Is your feature request related to a problem? Please describe.
When working with data having vertice property count in excess of 100 Postgres functions exhibit build - in limit of 100 arguments.
Examples:
function agtype_build_map treats each parameter as separate, map field name and map field value, hence, it limits input to 50 fields / call. To scale number of fields it can handle one has to continuously invoke constructs such as
agtype_add(
CypherInputParam_Var
, agtype_build_map(
/* 54 / field_name_54, field_value_54
/ 55 */ field_name_55, field_value_55
....
similarly when CREATE invoked subsequently in the context of call to cypher function and CypherInputParam_Var as an input parameter to overcome per call limit of parameters/properties requires to initially create subset of 50 fields and subsequently call constructs such as
CREATE (v:<vertice_name>
{... properties 1,2,3 ...
})
SET v += { properties 51... 100}
SET v += { properties 101... 150}
....
This limitation is grandfathered from functions servicing postgresql function check when using default build, as per Appendix K. PostgreSQL Limits document:
However, I am not 100% convinced that custom compilation of Postgres is the right approach in this case.
In an ideal world it would be nice if Age used under the hood an limit compatible with limit of Age, which I believe is 65,535 properties per vertice ( please correct me if I am wrong ).
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: