On Thu, Feb 23, 2006 at 12:54:52PM -0600, Kevin Grittner wrote:
> >>> On Wed, Feb 22, 2006 at 9:52 pm, in message
> <[EMAIL PROTECTED]>, Greg Stark <[EMAIL PROTECTED]> wrote:
>
>
> > "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> >
> >> There have been several times that I have run a SELECT COU
>>> On Wed, Feb 22, 2006 at 9:52 pm, in message
<[EMAIL PROTECTED]>, Greg Stark <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>
>> There have been several times that I have run a SELECT COUNT(*) on
an entire
>> table on all central machines. On identical hardware, wi
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> There have been several times that I have run a SELECT COUNT(*) on an entire
> table on all central machines. On identical hardware, with identical data,
> and equivalent query loads, the PostgreSQL databases have responded with a
> count in 50% to 7
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> We are replicating data from 72 source databases, each with the
> official copy of a subset of the data, to four identical consolidated
> databases, spread to separate locations, to serve our web site and other
> organization-wide needs. Currently, tw
Kevin,
On 2/22/06 8:57 AM, "Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> I hesitate to raise this issue again, but I've noticed something which I
> thought might be worth mentioning. I've never thought the performance
> of count(*) on a table was a significant issue, but I'm prepared to say
> th
I hesitate to raise this issue again, but I've noticed something which I
thought might be worth mentioning. I've never thought the performance
of count(*) on a table was a significant issue, but I'm prepared to say
that -- for me, at least -- it is officially and totally a NON-issue.
We are repli
