PFC wrote: > > Supposing your searches display results which are rows coming from one > specific table, you could create a cache table : > > search_id serial primary key > index_n position of this result in the global result set > result_id id of the resulting row. > > Then, making a search with 50k results would INSERT INTO cache ... SELECT > FROM search query, with a way to set the index_n column, which can be a > temporary sequence... > > Then to display your pages, SELECT from your table with index_n BETWEEN so > and so, and join to the data table.
This is a nice way of doing a fast materialized view. But it looked to me like one of the requirements of the original poster is that the result set being displayed has to be "current" as of the page display time. If inserts to the original table have been committed between the time the current page was displayed and "now", the next page view is supposed to show them. That basically means rerunning the query that was used to build the cache table. But perhaps the original poster is willing to live with the idea that new rows won't show up in the result set, as long as updates show up (because the cache table is just a fancy index) and deletes "work" (because the join against the data table will show only rows that are common between both). -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings