5 commits

Author	SHA1	Message	Date
Eelco Dolstra	5e6896b2d9	Turn prepared statements back on ... We once turned these off (in commit abe71a767b) because they caused the PostgreSQL query optimizer to use very suboptimal plans. However, PostgreSQL 9.2 has supposedly fixed this: http://www.postgresql.org/docs/9.2/static/release-9-2.html So let's try again.	2013-02-25 21:20:52 +01:00
Eelco Dolstra	e1768cae86	Don't barf if the SQLite DB is missing ... This prevented hydra-init from starting.	2012-03-19 03:57:11 +00:00
Eelco Dolstra	179b012a8e	Open the DB using Hydra::Model::DB->new ... This gets rid of the openHydraDB function and ensures that we open the database in a consistent way. Also drop the PostgreSQL sequence hacks. They don't seem to be necessary anymore.	2012-03-13 12:10:19 +01:00
Eelco Dolstra	abe71a767b	Disable prepared statements completely ... Because of the way DBIx::Class does prepared statements, even innocuous queries such $c->model('DB::Builds)->search({finished => 0}) can be extremely slow. This is because DBIx::Class prepares a PostgreSQL statement select ... from Builds where finished = ? and since Builds is very large and there is a large fraction of rows with "finished = 1", the PostgreSQL query planner decides to implement this query with a sequential scan of the Builds table (despite the existence of an index on "finished"), which is extremely slow. It would be nice if we could tell DBIx::Class that constants should be part of the prepared statement, i.e. select ... from Builds where finished = 0 but AFAIK we can't.	2012-03-12 20:47:30 +01:00
Eelco Dolstra	97ed2052ba	* Move everything up one directory.	2009-03-05 13:41:57 +00:00

Renamed from src/Hydra/lib/Hydra/Model/DB.pm (Browse further)