"Frank D. Engel, Jr." <[EMAIL PROTECTED]> writes:
> Yep, that could cause problems. Okay, now I'm joining the program.
>
> The only thing I can see that would fix this
> ...
There are well understood mechanisms to fix this. It's a "SMOP" or "simple
matter of programming". What you would do is
On 1/14/05 5:37 PM, "Martijn van Oosterhout" wrote:
> If that's all you want, what about the row estimate from pg_class? It
> has the number of rows active at last vacuum... For really large tables
> I imagine it'd be easily close enough...
For showing the changes in a given day (or even week),
On Fri, Jan 14, 2005 at 03:11:32PM -0800, Dann Corbit wrote:
> A cardinality estimate function might be nice.
> SELECT cardinality_estimate(table_name)
> If it is off by 25% then no big deal.
> It would be useful for the PostgreSQL query planner also, I imagine.
If that's all you want, what about
: Friday, January 14, 2005 2:59 PM
To: Postgres general mailing list
Subject: Re: [GENERAL] [HACKERS] Much Ado About COUNT(*)
On 1/14/05 12:47 PM, "Frank D. Engel, Jr." <[EMAIL PROTECTED]> wrote:
> It's probably too messy to be worthwhile this
> way, though. More trouble
On 1/14/05 12:47 PM, "Frank D. Engel, Jr." <[EMAIL PROTECTED]> wrote:
> It's probably too messy to be worthwhile this
> way, though. More trouble than it would be worth.
It would be rather useful if there was a way to get a reasonably accurate
count (better than analyze provides) in a very short
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yep, that could cause problems. Okay, now I'm joining the program.
The only thing I can see that would fix this for the integer would be
to keep track of the number of 'committed' records using the integer,
then for each new transaction, make a copy
On Fri, Jan 14, 2005 at 12:39:04PM -0500, Frank D. Engel, Jr. wrote:
> This is probably stupid for some reason, but why not use a 64-bit
> integer to track the number of records in the table? Increment when
> adding records, decrement when deleting them... then COUNT(*) could
> just return that
Frank D. Engel, Jr. wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is probably stupid for some reason, but why not use a 64-bit
integer to track the number of records in the table? Increment when
adding records, decrement when deleting them... then COUNT(*) could just
return that in c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is probably stupid for some reason, but why not use a 64-bit
integer to track the number of records in the table? Increment when
adding records, decrement when deleting them... then COUNT(*) could
just return that in cases where a query is known
Wes <[EMAIL PROTECTED]> writes:
> On 1/13/05 6:44 PM, "Greg Stark" <[EMAIL PROTECTED]> wrote:
>
> > That's simply false. Oracle does indeed have to count the records one by
> > one.
> Ok, I stand corrected - I was given some wrong information. However, my
> experience has been that count(*) on
On 1/13/05 6:44 PM, "Greg Stark" <[EMAIL PROTECTED]> wrote:
> That's simply false. Oracle does indeed have to count the records one by one.
>
> It doesn't have to read and ignore the dead records since they're in a
> separate place (but on the other hand it sometimes have to go read that
> separa
Wes <[EMAIL PROTECTED]> writes:
> On 1/13/05 9:50 AM, "Greg Stark" <[EMAIL PROTECTED]> wrote:
>
> Of course, in Oracle 'count(*)' is instantaneous. It doesn't have to count
> the physical records one by one.
That's simply false. Oracle does indeed have to count the records one by one.
It does
On 1/13/05 9:50 AM, "Greg Stark" <[EMAIL PROTECTED]> wrote:
> I think the Oracle syntax looks like
>
> SELECT * FROM foo SAMPLE (0.1)
>
> I don't think I would have picked this syntax but it seems like a better idea
> to copy the existing practice rather than invent a new one.
Of course, in O
[snip]
> See:
>
> http://www.jlcomp.demon.co.uk/faq/random.html
>
> I think the Oracle syntax looks like
>
> SELECT * FROM foo SAMPLE (0.1)
>
> I don't think I would have picked this syntax but it seems like a better idea
> to copy the existing practice rather than invent a new one.
>
> Th
Csaba Nagy <[EMAIL PROTECTED]> writes:
> [snip]
> > The database could be clever and implement the same kind of sampling vacuum
> > does. That picks a random sampling of pages from the table without using an
> > index. But there's no way to implement the same kind of behaviour from the
> > user-vi
[snip]
> The database could be clever and implement the same kind of sampling vacuum
> does. That picks a random sampling of pages from the table without using an
> index. But there's no way to implement the same kind of behaviour from the
> user-visible features.
... meaning perhaps a new keyword
David Garamond <[EMAIL PROTECTED]> writes:
> Merlin Moncure wrote:
> > 6. for large tables, you can get a pretty accurate count by doing:
> > select count(*) * 10 from t where random() > .9;
> > on my setup, this shaved about 15% off of the counting time...YMMV.
>
> That's an interesting idea, u
Merlin Moncure wrote:
6. for large tables, you can get a pretty accurate count by doing:
select count(*) * 10 from t where random() > .9;
on my setup, this shaved about 15% off of the counting time...YMMV.
That's an interesting idea, using sampling to get an estimate.
Thanks for the tip.
--
dave
-
18 matches
Mail list logo
