performance, index tuning etc
This commit is contained in:
@@ -31,37 +31,27 @@ hotspots or potential ones in small sample generation:
|
||||
todo: perf, test installed postgres vs standalone jimmied one for same op
|
||||
YES, very important to know this, is my cobbled together standalone postgres as good as installed or huge diff??
|
||||
|
||||
perf: UNIT unique indexes on names and serial numbers to speed up validation on create??
|
||||
Needs enough data to be a test, here's the check in sql:
|
||||
--after adding index on serial
|
||||
explain (analyze,buffers,timing)
|
||||
SELECT EXISTS (
|
||||
SELECT 1
|
||||
FROM aunit AS a
|
||||
WHERE ((a.serial = 'wqwerqwe') AND (a.unitmodelid = 7)) AND (a.id <> 0))
|
||||
|
||||
Execution Time: 0.087 ms
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_aunit_serial
|
||||
ON public.aunit USING btree
|
||||
(serial COLLATE pg_catalog."default" ASC NULLS LAST)
|
||||
CREATE INDEX IF NOT EXISTS idx_atranslationitem_key
|
||||
ON public.atranslationitem USING btree
|
||||
(key COLLATE pg_catalog."default" ASC NULLS LAST)
|
||||
TABLESPACE pg_default;
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_aunit_modelid
|
||||
ON public.aunit USING btree
|
||||
(unitmodelid ASC NULLS LAST)
|
||||
TABLESPACE pg_default;
|
||||
|
||||
|
||||
|
||||
SEEDING PERF LEVELS:
|
||||
2021-10-20 10:06:12.8367|INFO|Seeder|Small level sample data seeded in 16 seconds
|
||||
2021-10-20 10:29:52.5918|INFO|Seeder|MEDIUM level sample data seeded in 1 minute and 44 seconds
|
||||
#Added indexes to speed up validation on aunit for serial and modelid
|
||||
2021-10-20 10:35:34.5693|INFO|Seeder|MEDIUM level sample data seeded in 1 minute and 49 seconds
|
||||
2021-10-20 10:48:06.2517|INFO|Seeder|LARGE level sample data seeded in 4 minutes and 13 seconds
|
||||
# here removed unitmodelid index as it never seems to be used but serial is a lot
|
||||
2021-10-20 10:59:30.1027|INFO|Seeder|LARGE level sample data seeded in 4 minutes and 10 seconds
|
||||
# No difference so keeping only the serial index
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-------------------------------------
|
||||
todo: ops document where is the query timeout setting and how to adjust it for timeouts in long running queries?
|
||||
|
||||
todo: hard cap on appointments brought back controlled by client in settings otherwise unusable
|
||||
|
||||
Reference in New Issue
Block a user