From: Harry Jackson <harryjackson@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Suspending SELECTs
Date: Wed, 18 Jan 2006 15:41:57 +0000
Message-ID: <45b42ce40601180741q34553beeu134da075987e8232@mail.gmail.com> (raw)
In-Reply-To: <43CE5AC7.50407@barettadeit.com>
References: <43CB71AC.20203@barettadeit.com>
<9766.1137433907@sss.pgh.pa.us>
<43CD4BD0.9090807@barettadeit.com>
<20060117211259.GA13926@mark.mielke.cc>
<43CE030E.1070707@barettadeit.com>
<20060118143024.GA8402@mark.mielke.cc>
<43CE5AC7.50407@barettadeit.com>
Your experiment made far too many assumptions and the data does not
stand up to scrutiny.
On 1/18/06, Alessandro Baretta <a.baretta@barettadeit.com> wrote:
> Results: I'll omit the numerical data, which everyone can easily obtain in only
> a few minutes, repeating the experiment. I used several query strings containing
> very common words ("linux debian", "linux kernel", "linux tux"), each yielding
> millions of results. I set Google to retrieve 100 results per page. Then I ran
> the query and paged through the data set. The obvious result is that execution
> time is a monotonously growing function of the page number. This clearly
> indicates that Google does not use any algorithm of the proposed kind, but
> rather an OFFSET/LIMIT strategy, thus disproving the hypothesis.
I just ran the same test and I got a different outcome than you. The
last page came back twice as fast as page 4. I noticed no trend in the
speed of the results from each page.
Of course it is probably in cache because its such a common thing to
be searched on so the experiment is pointless.
You cannot jump to your conclusions based on a few searches on google.
> It must also be noted that Google refuses to return more than 1000 results per
> query, thus indicating that the strategy the adopted quite apparently cannot
> scale indefinitely, for on a query returning a potentially flooding dataset, a
> user paging through the data would experience a linear slowdown on the number of
> pages already fetched, and the DBMS workload would also be linear on the number
> of fetched pages.
There are various reason why google might want to limit the search
result returned ie to encourage people to narrow their search. Prevent
screen scrapers from hitting them really hard blah blah. Perhaps less
than 0.00000001% of real users (not scrapers) actually dig down to the
10th page so whats the point.
There are numerous methods that you can use to give separate result
pages some of which include going back to the database and some don't.
I prefer not to go back to the database if I can avoid it and if all
you want to do is provide a few links to further pages of results then
going back to the database and using offsets is a waste of IO.
--
Harry
http://www.hjackson.orghttp://www.uklug.co.uk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: harryjackson@gmail.com
Subject: Re: Suspending SELECTs
In-Reply-To: <45b42ce40601180741q34553beeu134da075987e8232@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox