Re: estimated_count() implementation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Volkan YAZICI" <yazicivo(at)ttnet(dot)net(dot)tr>, "Michael Fuhr" <mike(at)fuhr(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: estimated_count() implementation
Date: 2006-10-22 16:52:25
Message-ID: 6012.1161535945@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Sun, 2006-10-22 at 12:07 +0300, Volkan YAZICI wrote:
>> But OTOH, Tom's complaints look like still applicable for my
>> estimated_count() too. Does this TODO need a little bit more
>> clarification or we can count is a redundant one?

> http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php

> Is the source of the TODO item, though please read the upthread messages
> as to how we got there...

I think there is a use-case for something like

select estimated_count('select * from ... where ...');

i.e. there are applications where a possibly-bad estimate is enough.
What I'm concerned about is the level of complaints from newbies who'll
expect it to be dead accurate all the time ...

BTW, you can build estimated_count() today in a few lines of plpgsql:

create or replace function estimated_count(text) returns float8 as $$
declare r text;
begin
for r in execute 'explain ' || $1 loop
return substring(r from 'rows=([0-9]+) ');
end loop;
end$$ language plpgsql strict;

I don't see that it really justifies any more work than that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-10-22 17:18:07 Re: Updates for vcbuild
Previous Message Tom Lane 2006-10-22 16:12:04 Re: xlogdump fixups and WAL log question.