Parallel BG search does not always work

Bug #1129074 reported by Adrian Partl on 2013-02-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Spider for MySQL
Kentoku SHIBA

Bug Description

Spider engine version 3.0.

The parallel BG search does not always work, depending on the query one asks.
On a table with one primary key column (id) and one data column (data), the following
queries are correctly run in parallel if BG search is on:

id ranges from 3000000000 to 8500000000
data ranges from 0 to 1000

SELECT * from foo where id < 3000000010
SELECT * from foo where data > 1000.1

however the following query is run in sequential order, where each node is asked for
results sequentially:

SELECT * from foo where data > 999.9
SELECT * from foo where id > 3000000010
SELECT * from foo where id < 5000000010

With the data column the behavior seems to be dependent on the maximum value in the
table. I have no idea though, why the second and third query on the primary key column do
not run in parallel. Somehow this seems correlated with the amount of data returned (does
the optimiser play a role in this?)

Let me know if you need more information.

Kentoku SHIBA (kentokushiba) wrote :
Changed in spiderformysql:
assignee: nobody → Kentoku SHIBA (kentokushiba)
importance: Undecided → Medium
status: New → In Progress
Adrian Partl (ndriax) wrote :

I tried again with the sources you provided. The problem still remains whenh using the same configuration. Is there something I need to reconfigure? Or can I send you any other information that might help you?

Kentoku SHIBA (kentokushiba) wrote :

Thank you for checking! If you set "bgs_mode" >= 1, no need other configuration. Could you please give me the table structure and sample data for reproducing?

Adrian Partl (ndriax) wrote :

OK, "bgs_mode" is set to 1, so that was not the problem. I have dumped some data from one of our tables into
a CSV file, together with the CREATE TABLE statements for the nodes and the spider head node. I hope 100000
rows is enough? You can have more if you need...

Download the data here:

Adrian Partl (ndriax) wrote :


Thank you for your update! The bug is now fixed in the version you provided. It now works!

Thanks again,


Adrian Partl (ndriax) wrote :

Should a query like

delete from FOO.BAR where x < 87;

also be executed in parallel? If yes, this would not yet work with the version you provided.

Adrian Partl (ndriax) wrote :


I think this is still related to the issue I reported here. If not, feel free to open this as a new bug.

With the version you provided, a parallel BG query using ORDER BY and LIMIT will cause the server to crash
(I know the query is rather stupid with large tables since the head node needs to do the sorting right? But
still it should not take the server down):

select * from FOO order by BAR limit 10;

will crash. This will not crash however:

select * from FOO order by BAR;
select * from FOO limit 10;

Stacktrace from the log file is:


I'm happy to provide any other information that might help...


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers