Closed mkgrgis closed 2 years ago
Thanks for the report, I will take a look but it may be a few weeks before I get to this.
No problems, @ibarwick ! I'll try to prepare the smallest dataset for this issue. Surprisingly, this problem has nothing common with https://github.com/ibarwick/firebird_fdw/issues/13.
It may be interesting for comparation, https://github.com/pgspider/sqlite_fdw haven't issue for the same situation here discussed.
No problems, @ibarwick ! I'll try to prepare the smallest dataset for this issue. Surprisingly, this problem has nothing common with #13.
@mkgrgis Any chance of a dataset to reproduce this with? I hope to be able to take a look at this in the next few weeks.
Now there is only big dataset with 1345 rows from my first comment to this issue. I have some variants of mini datasets, but there is no errors. I'll make additional research to locate a problem.
Now there is only big dataset with 1345 rows from my first comment to this issue. I have some variants of mini datasets, but there is no errors. I'll make additional research to locate a problem.
Ah OK, I missed that attachment; that should be fine for now.
I have a version, error depends on a combination of cardinalities of objects in a plan of execution between DB's. All of my mini datasets (10..50 rows) haven't the error.
OK, I've finally had the time to work out what was causing this. The issue does not occur if the foreign table is analyzed; in this case a hash join is used. However, without any table statistics, the planner uses a merge join, which results in a rescan, which was not happening properly, leading to PostgreSQL only receiving a subset of the expected data. Fix is applied; I'll put out a new release in the next few days. Thanks once again for the report!
Thanks a lot, @ibarwick ! I have seen https://github.com/ibarwick/firebird_fdw/commit/de5a02bf8fdf994fd32a9a50acd6462ee0243f4d My version of problem's source was wrong. Not only cardinality, but rescan in complex with merge join. I'll try to use Your new code next week and then can to write if it's correct for release.
Verified. Works fine, @ibarwick! My congratulations for You! No problems to make a new release if You want.
Now libfq doesn't support only generic BLOB and arrays. In my experience there was no BLOB's in Firebird. For C-language Firebird interface there is some common algorithms for BLOB and arrays. I saw that arrays in Firebird C-code likes to special implicit BLOBs, but i haven't use arrays. If You want, i will help with arrays.
Firebird:
Sample data for Firebird Hierarchy.txt Some first lines is here.
Query for Firebird
No problems. First lines of result
and what we have in PostgreSQL 13?
The query
select * from hier;
is similar to query for Firebird. But for querywe get only levels 0 and 1 - this is the problem.
Final test for pg query. If we execute
create table hier2 as select * from hier;
and rewrite query to hier2, there is no problems with all levels.