The metabib.record_attr_flat view previously pulled its data
through several other intermediate views. While this improves
maintenance overhead, it ends up being an optimization fence
for certain data sets. So, we pull the logic from the leaf
views up into the main view. And, poof, 2 orders of magnitude
speedup on large data sets.
Signed-off-by: Mike Rylander <miker@esilibrary.com>
Signed-off-by: Ben Shum <bshum@biblio.org>
-- Back-compat view ... we're moving to an INTARRAY world
CREATE VIEW metabib.record_attr_flat AS
SELECT v.source AS id,
- m.attr,
- m.value
- FROM metabib.full_attr_id_map m
- JOIN metabib.record_attr_vector_list v ON ( m.id = ANY( v.vlist ) );
+ m.attr AS attr,
+ m.value AS value
+ FROM metabib.record_attr_vector_list v
+ LEFT JOIN metabib.uncontrolled_record_attr_value m ON ( m.id = ANY( v.vlist ) )
+ UNION
+ SELECT v.source AS id,
+ c.ctype AS attr,
+ c.code AS value
+ FROM metabib.record_attr_vector_list v
+ LEFT JOIN config.coded_value_map c ON ( c.id = ANY( v.vlist ) );
CREATE VIEW metabib.record_attr AS
SELECT id, HSTORE( ARRAY_AGG( attr ), ARRAY_AGG( value ) ) AS attrs FROM metabib.record_attr_flat GROUP BY 1;
--- /dev/null
+BEGIN;
+
+SELECT evergreen.upgrade_deps_block_check('XXXX', :eg_version);
+
+CREATE OR REPLACE VIEW metabib.record_attr_flat AS
+ SELECT v.source AS id,
+ m.attr AS attr,
+ m.value AS value
+ FROM metabib.record_attr_vector_list v
+ LEFT JOIN metabib.uncontrolled_record_attr_value m ON ( m.id = ANY( v.vlist ) )
+ UNION
+ SELECT v.source AS id,
+ c.ctype AS attr,
+ c.code AS value
+ FROM metabib.record_attr_vector_list v
+ LEFT JOIN config.coded_value_map c ON ( c.id = ANY( v.vlist ) );
+
+COMMIT;
+