Hi,
the prefilter makes it faster, but somehow i get three times more tupels in the result than before. How is that possible?
((calls.sample_id BETWEEN 226 AND 369) AND calls.sample_id IN (227, 230, 233, 234, 237, 190, 195, 198, 199, 203, 270, 273, 276, 189, 343, 366, 367, 368))) AS anon_2
Best regards,
Martin
Am 25.06.2015 um 22:08 schrieb Martin Kersten <martin@monetdb.org>:
Hi
On 25/06/15 17:38, Martin Schwitalla wrote:
...
I added some primary and foreign key constraints and set the database to
readonly, but it didn`t do much. The trace tells me that some joins take the
most time and some subselects also take much time. But nothing besides that.
The query has 10 joins.
... Indeed a complex, probably generated SQL query.
The trace information of the expensive joins and thetaselects
would be my first target.
An expensive join might typically result if its hash support
does not fit in memory, which will cause disk accesses.
The predicate (calls.sample_id IN (227, 230, 233,....
and the like probably produce to multiple thetaselect that
are merged in the end. It might help (worth trying)
to put a range pre-filter (call.sample between 227 and 368 and calls.sample in (227,....))
The fact that minimal-pipe is better then the default-pipe
indicates a lot of competition for scarce resources during
execution.
regards, Martin
_______________________________________________
users-list mailing list
users-list@monetdb.org
https://www.monetdb.org/mailman/listinfo/users-list
_______________________________________________
users-list mailing list
users-list@monetdb.orghttps://www.monetdb.org/mailman/listinfo/users-list