Hi Robert,

Could you possibly check whether the join itself or the projection is the problem? The result is only 30 rows, but how many columns?

To do so, replace the * in the select clause by a single column name, e.g., xid.

If that works fast, the join itself is less of a problem.

Further: how does your query fail, I.e., what's the exact error?

Which version of MonetDB are you using and on which OS and what kind of hardware are you running?

Thanks!

Best,
Stefan


On January 21, 2015 12:02:59 AM CET, gms_xy@gmx.de wrote:
As mentioned in previous posts, I have some use cases for MonetDB, which act on tables with a billion rows. MonetDB works fast and stable on straight SELECT statements or aggregates on single tables

Problems occured when doing big joins, which should produce a result set of 30 rows only, but running hours before failing.

SELECT
   tbl1.*,
   tbl2.*
FROM
   tbl1,
   tbl2
WHERE
   tbl1.xid = tbl2.xid
   AND tbl1.pk = 12345678

(same behavior, if written with JOIN explicitly)


So I am wondering, if I can help MonetDB with partitioning or sharding.

Asked already here:
https://www.monetdb.org/pipermail/developers-list/2014-October/004325.html
What is the state regarding manual partitioning?


During last weeks I saw significant
acceleration with sharding on other DBMS. Is there anybody, who can give some introduction or share experiences with sharding on MonetDB? 3rd party tools?

What ist the maximum number of tables within a MonetDB database? What is the estimated overhead of a single table, multiplied a million times?

Thank you

Robert


users-list mailing list
users-list@monetdb.org
https://www.monetdb.org/mailman/listinfo/users-list

--
| Stefan.Manegold@CWI.nl | DB Architectures (DA) |
| www.CWI.nl/~manegold/ | Science Park 123 (L321) |
| +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |