X-Git-Url: https://gitweb.michael.orlitzky.com/?a=blobdiff_plain;f=doc%2Fproject_overview%2Findex.xhtml;h=3201609ff353831172b13b440e926a270903e302;hb=730af6c2b7cc3b82a45fe8cdff720c13892316cb;hp=051e56782b7203b6967033559ea4ec44a477c8b9;hpb=935a6ead0912829a7e0f153aa7aac7494977e69c;p=dead%2Fcensus-tools.git diff --git a/doc/project_overview/index.xhtml b/doc/project_overview/index.xhtml index 051e567..3201609 100644 --- a/doc/project_overview/index.xhtml +++ b/doc/project_overview/index.xhtml @@ -269,5 +269,79 @@ States.
++ There are a number of possible optimizations that can be made + should performance ever become prohibitive. To date, these have + been eschewed for lack of flexibility and/or development time. +
+ ++ Currently, the TIGER/Line block data is stored in a separate table + from the Summary File 1 block data. The two are combined at query + time via SQL + JOINs. Since we import the TIGER data first, and use a custom + import script for SF1, we could de-normalize + this design to increase query speed. +
+ ++ This would slow down the SF1 import, of course; but the import + only needs to be performed once. The procedure would look like the + following: +
+ ++ When the TIGER data is imported via shp2pgsql, a GiST + index is added to the geometry column by means of the + -I flag. This improves the performance of the + population calculations by a (wildly-estimates) order of + magnitude. +
+ ++ Postgres, however, offers another type of similar index — + the GIN + Index. If performance degrades beyond what is acceptable, it + may be worth evaluating the benefit of a GIN index versus the GiST + one. +
+