:garvan Reporter
	Description • 7 years ago

- In the DB, favicon views are filled with NULL data. For instance `view_history_id_favicon` gets a row of null data every history item. In my case 20000 rows of multi-column null data. 
- Anywhere we join with favicons, we get get 4/5 columns added (of NULLs).
- Actual favicon lookup in the code is done as-needed. Even on an iPad, the UI can only show a small bounded number of favicons on the screen at a time, and it is performant to lookup by index (for a single favicon is 1ms on my iPhone).
- When investigating frecency query performance, I found the favicon table join in that query was adding 15% to the query time. We do favicon table joins in many places in the code, thus we may get a perf boost by removing this.
- confusing as a dev on the storage layer to keep running into null/empty data

	Richard Newman [:rnewman]
	Comment 1 • 7 years ago

Reminder: views are not stored anywhere; they're just a saved query. There is no additional file size beyond the view definition itself in the schema table.

	:garvan Reporter
	Comment 2 • 7 years ago

Good point regarding views, and to correct a point in my description: this bug won't affect file size.
Those are views that are showing 20K rows of nulls (or 4/5 extra null columns of icon info) and I don't see a table in DB that is affected by this bug. It is all 'downstream' of the tables, in the views where the problems lie.