From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 257151F404; Wed, 28 Mar 2018 21:40:02 +0000 (UTC) Date: Wed, 28 Mar 2018 21:40:01 +0000 From: Eric Wong To: Jonathan Corbet Cc: meta@public-inbox.org Subject: Re: [PATCH] Allow specification of the number of search results to return Message-ID: <20180328214001.GA21992@untitled> References: <20180326163431.03fe26bc@lwn.net> <20180327104457.GA15422@80x24.org> <20180328150031.40df6080@lwn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180328150031.40df6080@lwn.net> List-Id: Jonathan Corbet wrote: > On Tue, 27 Mar 2018 10:44:57 +0000 > Eric Wong wrote: > > Jonathan Corbet wrote: > > > Add an "l=" parameter to the search query syntax to specify how many > > > results should be returned. The default remains 200. > > > --- > > > 200 is a lot of results for one page, so allow it to be tweaked. I've not > > > added anything to the query form to access this (don't need it) but could. > > > > There's the "feedmax" config variable, perhaps a config option > > along those lines can be used with search results. > > That would solve my problem nicely, but takes the control out of the hands > of the reader. Is this the approach you would rather see? I think we can support both a user-specified "l=" AND have a configurable max as a safety measure. > > Blindly trusting user input here could cause memory problems on > > the server and should be clamped to a reasonable value. > > Yeah...I saw it sort of like the threat from doing a lot of simultaneous > searches. It's better to limit it, though; I can certainly do that if you > don't prefer the config-option approach. Please do, thanks. Several smaller, simultaneous searches is less overhead on the server than one giant one since as it allows fairer scheduling.