On 8/16/07, Rainer Bauer <usenet@munnin.com> wrote:
> "Trevor Talbot" wrote:
>
> >On 8/16/07, Rainer Bauer <usenet@munnin.com> wrote:
> >
> >> My point is that whatever search criterias are involved and how many items are found eBay always returns the
*accurate*number of items found.
> >>
> >> Before this drifts off:
> >> * I do know *why* count(*) is slow using Postgres.
> >> * I *think* that count(*) is fast on eBay because count is cheaper using Oracle (which eBay does:
<http://www.sun.com/customers/index.xml?c=ebay.xml>).
> >> * I realize that pagination for multi-million tuple results does not make sense.
> >
> >You got me curious, so I went hunting for more hints on what eBay
> >actually does, and found these slides from a presentation given by two
> >eBay engineers last year:
> >http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
>
> Quite interesting.
>
> >It's, er, a whole different ballgame there. Database behavior is
> >barely involved in their searching; they do joins and RI across
> >database clusters within the _application_. I knew eBay was big, but
> >wow...
>
> Well then: forget the Oracle count(*) argument :-(
FYI, I went to the ebay page you posted, which listed something like
98011 pages, and asked for page 96000. It searched for about a minute
and timed out with the error message
There was a problem executing your request. Please try again.
Tried it again, twice, about 5 minutes apart, and got the same error each time.
So I'm guessing that ebay is better at making your THINK it has the
exact count than actually having the exact count.
