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
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. |