Re: [PERFORM] query optimization differs between view and explicit

2004-01-30 Thread Reece Hart
ays add it themselves to achieve what I was doing in the explicit query. I appreciate your time. -Reece -- Reece Hart, http://www.in-machina.com/~reece/, GPG:0x25EC91A0

[PERFORM] query optimization differs between view and explicit query

2004-01-29 Thread Reece Hart
I have a large query which I would like to place in a view. The explicit query is sufficiently fast, but the same query as a view is much slower and uses a different plan. I would appreciate an explanation of why this is, and, more importantly whether/how I might coax the view to use a differen

[PERFORM] explicit casting required for index use

2003-10-26 Thread Reece Hart
tional indexes would apply only to immutable fx only, but that's fine.) Thanks, Reece -- Reece Hart, Ph.D. [EMAIL PROTECTED], http://www.gene.com/ Genentech, Inc. 650/225-6133 (voice), -5389 (fax) Bioinformatics and Protein Engineering 1 DNA Way,

Re: [PERFORM] Perfomance Tuning

2003-08-11 Thread Reece Hart
emphasizes that journals probably work best with short burst writes and syncing during lulls rather than sustained writes. I ended up solving the update issue without really updating, so ext2 timings aren't known. So, you may want to test this yourself if you're concerned. -Reece -- Ree

Re: [PERFORM] slow table updates

2003-07-23 Thread Reece Hart
1161854174633 p2thread_pmodel_id  |   123243 | 1009606656 | 0.0430003860830331 paprospect2_redundant_alignment |   229934 | 1883619328 | 0.0230479032332376 What do you make of 'em apples? Thanks, Reece -- Reece Hart, Ph.D. [EMAIL PROTECTED

Re: [PERFORM] slow table updates

2003-07-23 Thread Reece Hart
ly done... Thanks, Reece -- Reece Hart, Ph.D. [EMAIL PROTECTED], http://www.gene.com/ Genentech, Inc. 650/225-6133 (voice), -5389 (fax) Bioinformatics and Protein Engineering 1 DNA Way, MS-93http://www.in-machina.com/~reece/ South

[PERFORM] slow table updates

2003-07-22 Thread Reece Hart
a supertable with the same name as an extant column in a subtable, it appears that such "merged definition" columns do not have the same properties as a typical inherited column. In particular, dropping the column from the supertable does not drop it from the subta