Conversation
labkey-jeckels
left a comment
labkey-jeckels
left a comment
There was a problem hiding this comment.
See comment on Luminex Postgres index. Otherwise, tested and looks good.
| -- This index overlaps with uq_analyte_lsid | ||
| DROP INDEX luminex.ix_luminexdatarow_lsid; |
There was a problem hiding this comment.
uq_analyte_lsid is on a different table. luminex.analyte vs luminex.datarow. Am I missing something?
There was a problem hiding this comment.
Yes, it's confusing... but if you look at the PostgreSQL luminex-0.000-23.000.sql script, you'll see:
CREATE INDEX IX_LuminexDataRow_LSID ON luminex.Analyte (LSID);
Based on the name and the fact that the SQL Server script has:
CREATE INDEX IX_LuminexDataRow_LSID ON luminex.DataRow (LSID);
...I concluded that the PostgreSQL definition is flat-out wrong. That's why the new incremental script recreates this index (correctly) after the drop statements. Also why there are six index drops on SQL Server and seven on PostgreSQL (that was my first clue that something must be off).
There was a problem hiding this comment.
Oh, interesting. I saw that the scripts were different in this PR but didn't realize it was because the original script was wrong.
Yes, this seems like the correct fixup now. I swear that I saw IX_LuminexDataRow_LSID on datarow when looking directly in the DB, but maybe I was just checking the SQLServer side.
| -- This index overlaps with uq_analyte_lsid | ||
| DROP INDEX luminex.ix_luminexdatarow_lsid; |
There was a problem hiding this comment.
Oh, interesting. I saw that the scripts were different in this PR but didn't realize it was because the original script was wrong.
Yes, this seems like the correct fixup now. I swear that I saw IX_LuminexDataRow_LSID on datarow when looking directly in the DB, but maybe I was just checking the SQLServer side.
2 participants
Rationale
Our utility has pointed out some redundant indices in ms2, luminex, and prot