On Jan 9, 2008 10:21 AM, Ivan Sergio Borgonovo <[EMAIL PROTECTED]> wrote:
> On Wed, 09 Jan 2008 16:33:54 +0200
> Sim Zacks <[EMAIL PROTECTED]> wrote:
>
> > Using count(*) is not bad design, though generally it makes sense
> > to use it with a where.
>
> I got the impression from others comments that postgresql
> under perform other DB even when a where clause on indexed column is
> involved.
Correct, see my other post. Again though, it's a tradeoff. This one
lower performing action allows other actions to be faster.
> Again: paging records. You can't do statistics.
Sure you can. When you're near the front, no one cares how exact it
is. Ever search for a common term on google? You don't get an exact
count, you get an approximation, and you get it for a reason.
Other sites often lie, and give what looks like an exact count, but if
it's in the 100,000 who really cares? Seriously, are you going to
10,000th page on google for a search term? If someone does start
going that far out, the cost of limit/offset are going to kick in, and
not just in postgresql, and queries are going to take longer and
longer. At that point, you can switch to an exact count(*) if you
need to have it. It won't be the most expensive thing you're doing.
> Still everybody knows that a frequent complain about postgresql is it
> has a slow count.
I've never heard it before (just kidding). I do think it's frequent.
I also think it's overstated.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
