tickets: 1453
This data as json
id | created | changetime | last_pulled_from_trac | stage | status | component | type | severity | version | resolution | summary | description | owner | reporter | keywords | easy | has_patch | needs_better_patch | needs_tests | needs_docs | ui_ux |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1453 | 2006-03-02 18:14:22 | 2014-02-09 12:48:37 | 2022-03-06 03:23:23.472808 | Accepted | closed | Generic views | New feature | Normal | worksforme | generic views sometimes inefficient with large data sets - especially archive_index | archive_index will give a list of years with available data to the template in the context. To discover these years, it will do the following SQL: {{{ SELECT DATE_TRUNC(\'year\', "logviewer_message"."time") FROM "logviewer_message" WHERE ("logviewer_message"."channel_id" = 2 AND "logviewer_message"."time" <= 2006-03-02 12:07:20.758531) GROUP BY 1 ORDER BY 1 ASC }}} This is rather icky if you have very much data in your database. For example the IRC logger currently has over 100000 messages stored for the #django channel. It will do an index scan for the timestamp - but that is allways "now" in archive_index, so it won't help much. It will essentially dig through all rows sequentially. I think either this list of years should be thrown out or should be made optional (add a with_list_of_years parameter to the generic view that people can set if they need this behaviour). | zefciu | hugo | 0 | 1 | 1 | 0 | 0 | 0 |