Skip Menu |

This queue is for tickets about the Fey-Loader CPAN distribution.

Report information
The Basics
Id: 49493
Status: resolved
Priority: 0/
Queue: Fey-Loader

People
Owner: Nobody in particular
Requestors: gq1 [...] sanger.ac.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Fey loader and large database
Date: Mon, 07 Sep 2009 17:05:46 +0100
To: bug-fey-loader [...] rt.cpan.org, autarch [...] urth.org
From: Guoying Qi <gq1 [...] sanger.ac.uk>
hi, there. I am using Fey::Loader to load my database schema into Perl, with around 40 tables. In the test and dev database, it works perfectly. But for the production database, it takes more than 10 minutes to load the schema in. (more than 100GB data in the live database in total). I am wondering whether you have options for Fey::Loader to only load a few tables in and don't check the data. Thanks. Guoying Qi -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Subject: Re: [rt.cpan.org #49493] Fey loader and large database
Date: Mon, 7 Sep 2009 11:15:55 -0500 (CDT)
To: Guoying Qi via RT <bug-Fey-Loader [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Mon, 7 Sep 2009, Guoying Qi via RT wrote: Show quoted text
> I am using Fey::Loader to load my database schema into Perl, with around > 40 tables. In the test and dev database, it works perfectly. > > But for the production database, it takes more than 10 minutes to load > the schema in. (more than 100GB data in the live database in total). > > I am wondering whether you have options for Fey::Loader to only load a > few tables in and don't check the data.
Fey::Loader should _only_ look at the schema definition. It never looks at the data in the tables. I have no idea why having a large database would make any difference here. Can you do some further debugging on this? Maybe try to figure out where exactly it's so slow in the Fey::Loader code? This may be specific to your DBMS (you didn't mention which one!) and or your particular version of that DBMS. Unfortunately, I do not have any huge databases lying around to test with ;) -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
Subject: RE: [rt.cpan.org #49493] Fey loader and large database
Date: Mon, 7 Sep 2009 22:31:35 +0100
To: <bug-Fey-Loader [...] rt.cpan.org>
From: "Guoying Qi" <gq1 [...] sanger.ac.uk>
Subject: Re: [rt.cpan.org #49493] Fey loader and large database <URL: https://rt.cpan.org/Ticket/Display.html?id=49493 > Fey::Loader should _only_ look at the schema definition. It never looks at the data in the tables. I have no idea why having a large database would make any difference here. Can you do some further debugging on this? Maybe try to figure out where exactly it's so slow in the Fey::Loader code? This may be specific to your DBMS (you didn't mention which one!) and or your particular version of that DBMS. Unfortunately, I do not have any huge databases lying around to test with ;) ----------------- Hi, Dave Thank you very much for your quick response. I am using MySQL 5.067. There are 41 tables in this database. There is no problems for me to use Fey::Loader against our dev and test database. There is not much data in them. I did a little bit debugging just now against our live database. When I set DBI_TRACE level to 1, I can see the script went through each table very quickly at the beginning, doing three things for each table: primary_key_info, column_info, statistics_info. And then keep trying to get foreign_key_info for each table. (each takes around 20 seconds, some steps may be longer, in total around 7-8 minutes). This foreign key info things mainly cause problems. Is there any way I can turn it off or make it quick? I will do more test tomorrow. Thanks for the help. Regards, Guoying Qi <- foreign_key_info(undef, 'npgqcp', ...)= DBI::st=HASH(0xa29f120) at mysql.pm line 166 <- fetchrow_hashref= undef row-1 at DBI.pm line 299 <- DESTROY(DBI::st=HASH(a23c898))= undef at DBI.pm line 323 <- foreign_key_info(undef, 'npgqcp', ...)= DBI::st=HASH(0xa29f0e0) at mysql.pm line 166 <- fetchrow_hashref= undef row-1 at DBI.pm line 299 <- DESTROY(DBI::st=HASH(a29f180))= undef at DBI.pm line 323 <- foreign_key_info(undef, 'npgqcp', ...)= DBI::st=HASH(0xa23c708) at mysql.pm line 166 <- fetchrow_hashref= undef row-1 at DBI.pm line 299 <- DESTROY(DBI::st=HASH(a29f1f0))= undef at DBI.pm line 323 When I set to DBI_TRACE to 2, the log message like below. <-- dbd_st_finish <- fetchrow_hashref= undef row-1 at DBI.pm line 299 -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x9f64458)~INNER) Freeing 2 parameters, bind 0 fbind 0 <- DESTROY= undef at DBI.pm line 323 -> foreign_key_info for DBD::mysql::db (DBI::db=HASH(0x9f01970)~0x9f01ab0 undef 'npgqcp' 'lane_qc' undef undef undef) -> dbd_st_prepare MYSQL_VERSION_ID 50051, SQL statement: SELECT NULL AS PKTABLE_CAT, A.REFERENCED_TABLE_SCHEMA AS PKTABLE_SCHEM, A.REFERENCED_TABLE_NAME AS PKTABLE_NAME, A.REFERENCED_COLUMN_NAME AS PKCOLUMN_NAME, A.TABLE_CATALOG AS FKTABLE_CAT, A.TABLE_SCHEMA AS FKTABLE_SCHEM, A.TABLE_NAME AS FKTABLE_NAME, A.COLUMN_NAME AS FKCOLUMN_NAME, A.ORDINAL_POSITION AS KEY_SEQ, NULL AS UPDATE_RULE, NULL AS DELETE_RULE, A.CONSTRAINT_NAME AS FK_NAME, NULL AS PK_NAME, NULL AS DEFERABILITY, NULL AS UNIQUE_OR_PRIMARY FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE A, INFORMATION_SCHEMA.TABLE_CONSTRAINTS B WHERE A.TABLE_SCHEMA = B.TABLE_SCHEMA AND A.TABLE_NAME = B.TABLE_NAME AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.CONSTRAINT_TYPE IS NOT NULL AND A.REFERENCED_TABLE_SCHEMA = ? AND A.REFERENCED_TABLE_NAME = ? ORDER BY A.TABLE_SCHEMA, A.TABLE_NAME, A.ORDINAL_POSITION Show quoted text
>- dbd_st_free_result_sets
<- dbd_st_free_result_sets RC -1 <- dbd_st_free_result_sets Show quoted text
>count_params statement SELECT NULL AS PKTABLE_CAT,
A.REFERENCED_TABLE_SCHEMA AS PKTABLE_SCHEM, A.REFERENCED_TABLE_NAME AS PKTABLE_NAME, A.REFERENCED_COLUMN_NAME AS PKCOLUMN_NAME, A.TABLE_CATALOG AS FKTABLE_CAT, A.TABLE_SCHEMA AS FKTABLE_SCHEM, A.TABLE_NAME AS FKTABLE_NAME, A.COLUMN_NAME AS FKCOLUMN_NAME, A.ORDINAL_POSITION AS KEY_SEQ, NULL AS UPDATE_RULE, NULL AS DELETE_RULE, A.CONSTRAINT_NAME AS FK_NAME, NULL AS PK_NAME, NULL AS DEFERABILITY, NULL AS UNIQUE_OR_PRIMARY FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE A, INFORMATION_SCHEMA.TABLE_CONSTRAINTS B WHERE A.TABLE_SCHEMA = B.TABLE_SCHEMA AND A.TABLE_NAME = B.TABLE_NAME AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.CONSTRAINT_TYPE IS NOT NULL AND A.REFERENCED_TABLE_SCHEMA = ? AND A.REFERENCED_TABLE_NAME = ? ORDER BY A.TABLE_SCHEMA, A.TABLE_NAME, A.ORDINAL_POSITION <- dbd_st_prepare -> dbd_st_execute for 09f64498 Show quoted text
>- dbd_st_free_result_sets
<- dbd_st_free_result_sets RC -1 <- dbd_st_free_result_sets mysql_st_internal_execute MYSQL_VERSION_ID 50051 Show quoted text
>parse_params statement SELECT NULL AS PKTABLE_CAT,
A.REFERENCED_TABLE_SCHEMA AS PKTABLE_SCHEM, A.REFERENCED_TABLE_NAME AS PKTABLE_NAME, A.REFERENCED_COLUMN_NAME AS PKCOLUMN_NAME, A.TABLE_CATALOG AS FKTABLE_CAT, A.TABLE_SCHEMA AS FKTABLE_SCHEM, A.TABLE_NAME AS FKTABLE_NAME, A.COLUMN_NAME AS FKCOLUMN_NAME, A.ORDINAL_POSITION AS KEY_SEQ, NULL AS UPDATE_RULE, NULL AS DELETE_RULE, A.CONSTRAINT_NAME AS FK_NAME, NULL AS PK_NAME, NULL AS DEFERABILITY, NULL AS UNIQUE_OR_PRIMARY FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE A, INFORMATION_SCHEMA.TABLE_CONSTRAINTS B WHERE A.TABLE_SCHEMA = B.TABLE_SCHEMA AND A.TABLE_NAME = B.TABLE_NAME AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.CONSTRAINT_TYPE IS NOT NULL AND A.REFERENCED_TABLE_SCHEMA = ? AND A.REFERENCED_TABLE_NAME = ? ORDER BY A.TABLE_SCHEMA, A.TABLE_NAME, A.ORDINAL_POSITION Binding parameters: SELECT NULL AS PKTABLE_CAT, A.REFERENCED_TABLE_SCHEMA AS PKTABLE_SCHEM, A.REFERENCED_TABLE_NAME AS PKTABLE_NAME, A.REFERENCED_COLUMN_NAME AS PKCOLUMN_NAME, A.TABLE_CATALOG AS FKTABLE_CAT, A.TABLE_SCHEMA AS FKTABLE_SCHEM, A.TABLE_NAME AS FKTABLE_NAME, A.COLUMN_NAME AS FKCOLUMN_NAME, A.ORDINAL_POSITION AS KEY_SEQ, NULL AS UPDATE_RULE, NULL AS DELETE_RULE, A.CONSTRAINT_NAME AS FK_NAME, NULL AS PK_NAME, NULL AS DEFERABILITY, NULL AS UNIQUE_OR_PRIMARY FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE A, INFORMATION_SCHEMA.TABLE_CONSTRAINTS B WHERE A.TABLE_SCHEMA = B.TABLE_SCHEMA AND A.TABLE_NAME = B.TABLE_NAME AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.CONSTRAINT_TYPE IS NOT NULL AND A.REFERENCED_TABLE_SCHEMA = 'npgqcp' AND A.REFERENCED_TABLE_NAME = 'lane_qc' ORDER BY A.TABLE_SCHEMA, A.TABLE_NAME, A.ORDINAL_POSITION <- dbd_st_execute returning imp_sth->row_num 0 <- foreign_key_info= DBI::st=HASH(0x9f64198) at mysql.pm line 166 -> fetchrow_hashref for DBD::mysql::st (DBI::st=HASH(0x9f64198)~0x9f64288) -> dbd_st_FETCH_attrib for 09f64498, key NAME_uc -> dbd_st_FETCH_attrib for 09f64498, key NAME -> dbd_st_fetch dbd_st_fetch for 09f64498, chopblanks 0 dbd_st_fetch result set details imp_sth->result=09fa7180 mysql_num_fields=15 mysql_num_rows=0 mysql_affected_rows=0 dbd_st_fetch for 09f64498, currow= 1 dbd_st_fetch, no more rows to fetch --> dbd_st_finish Show quoted text
>- dbd_st_free_result_sets
<- dbd_st_free_result_sets RC -1 <- dbd_st_free_result_sets -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Weird. I suspect this is a problem in either MySQL itself or DBD::mysql's implementation of foreign_key_info. I'd suggest you report this to the MySQL folks as a bug against DBD::mysql, and they can do a better job figuring out where the problem is (http://bugs.mysql.com/). I'm quite sure it's nothing specific to Fey::Loader, since all I do is call foreign_key_info and do some processing on the results. There's now easy way to disable this in Fey::Loader, though you could monkey patch in a no-op in place of _fk_info_sth: { package Fey::Loader::mysql; sub _fk_info_sth { return } } Of course, you won't get any foreign keys in your schema this way. I'm going to close this bug, so please don't respond directly to it, or the it will be re-opened.
On Mon Sep 07 17:43:02 2009, DROLSKY wrote: Show quoted text
> Weird. I suspect this is a problem in either MySQL itself or DBD::mysql's > implementation of foreign_key_info. > > I'd suggest you report this to the MySQL folks as a bug against > DBD::mysql, and they can do a better job figuring out where the problem > is (http://bugs.mysql.com/). > > I'm quite sure it's nothing specific to Fey::Loader, since all I do is > call foreign_key_info and do some processing on the results.
Although it wouldn't hurt for you to double check this. You can write a small script which makes a plain DBI handle and calls foreign_key_info on your big database and iterates over the results. But really, I can't see how Fey::Loader could be the problem here.