Re: Records Number

Lists: pgsql-general
From: Enrico Pirozzi <sscotty71(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Records Number
Date: 2009-03-17 11:16:20
Message-ID: 5d038c780903170416m5d175126p6249773883fa69fb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Hi all,
I have a little problem,

I would like to execute

select * from table

and i would like to retrieve the number of records without make

select count(*) from table

I could use directly the table instead of select, and in this this
case I'm searching for
something like the reltuples field in the pg_class table, but I need
this value in real time.

Any suggestion?

Enrico
--
That's one small step for man; one giant leap for mankind

Enrico Pirozzi
Tel. +39 0861 1855771
Mob.+39 328 4164437
Fax +39 0861 1850310
www.enricopirozzi.info
info(at)enricopirozzi(dot)info
Skype sscotty71


From: Richard Huxton <dev(at)archonet(dot)com>
To: info(at)enricopirozzi(dot)info
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Records Number
Date: 2009-03-17 12:26:34
Message-ID: 49BF96FA.3020905@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Enrico Pirozzi wrote:
> and i would like to retrieve the number of records without make
>
> select count(*) from table
>
> I could use directly the table instead of select, and in this this
> case I'm searching for
> something like the reltuples field in the pg_class table, but I need
> this value in real time.

If you want an accurate, up-to-date count then you'll need to use
count(*) or have a trigger keep a summary-count for you. A simple
implementation will reduce concurrency to writes on that table however.
Lots of discussion in the mailing-list archives on this.

--
Richard Huxton
Archonet Ltd


From: Enrico Pirozzi <sscotty71(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Records Number
Date: 2009-03-17 14:09:02
Message-ID: 5d038c780903170709s18793918g1b82e06996951d1a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

> If you want an accurate, up-to-date count then you'll need to use
> count(*) or have a trigger keep a summary-count for you. A simple
> implementation will reduce concurrency to writes on that table however.

Yes I solved by a trigger....

> Lots of discussion in the mailing-list archives on this.

Thank you for your time

Enrico

--
That's one small step for man; one giant leap for mankind

Enrico Pirozzi
Tel. +39 0861 1855771
Mob.+39 328 4164437
Fax +39 0861 1850310
www.enricopirozzi.info
info(at)enricopirozzi(dot)info
Skype sscotty71


From: Thomas Kellerer <spam_eater(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Records Number
Date: 2009-03-17 14:34:55
Message-ID: gpoceg$js6$1@ger.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Richard Huxton, 17.03.2009 13:26:
> Enrico Pirozzi wrote:
>> and i would like to retrieve the number of records without make
>>
>> select count(*) from table
>>
>> I could use directly the table instead of select, and in this this
>> case I'm searching for
>> something like the reltuples field in the pg_class table, but I need
>> this value in real time.
>
> If you want an accurate, up-to-date count then you'll need to use
> count(*) or have a trigger keep a summary-count for you. A simple
> implementation will reduce concurrency to writes on that table however.
> Lots of discussion in the mailing-list archives on this.
>
Can a trigger solution really give an accurate count in a concurrent insert/delete scenario?

Thomas


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Kellerer <spam_eater(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Records Number
Date: 2009-03-17 14:39:58
Message-ID: 8596.1237300798@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Thomas Kellerer <spam_eater(at)gmx(dot)net> writes:
> Can a trigger solution really give an accurate count in a concurrent insert/delete scenario?

In principle yes, but AFAIK no one has really coded it up in full
detail. See the design that was hashed out in some previous
mailing-list thread, involving delta-count records entered into
a tracking table by each transaction that inserts or deletes.

regards, tom lane