After experimenting a bit with the PageSearch web control, I've found out that any constraints (PropertyCriterias) seem to be carried out as a post DB operation. In this case, this is kind of severe from a performance perspective. We want to limit our search to pages of one specific page type, but still use the search query function. We have many thousands pages and if you set the MaxAllowHits parameter to 100 you will end up with a net result of about 2 hits for a common search keyword: Example: search for "stock" generates many hits. I've set the search query and added a required property criteria (PageTypeID=X). What happens is that MaxAllowHits are fetched from the database (thus missing out on MANY hits), then 99% is taken away since they are not of page type X. Result: few hits = not good. Question: are the top ranked one returned at least? Ok....so raise the MaxAllowHits parameter then you say. Yes, feasible, but then performance degrades. Isn't there someway to carry out constraints already in the SQL query executed by EPiServer?? What does it actually mean to set a property to searchable in admin mode? Index Server kicks in? SQL indexes are generated? From a EPiServer SQL function? Third question: using automatic paging in the PageSearch control, I see that ViewState isn't approaching really high levels. Does that mean that SQL is carried out to fetch say posts 21-40 for instance on search page changes. If so, is that accomplished by using a temporary table in the SQL? Any ways to change this behavior? Or is the page data collection cached for some time in EPiServer rather than written to view state? If so, for how long? Regards