Geo Carncross wrote:
> I completely agree with this. There's just the problem of databases
> being a moving target. Remember we talked about COUNT(*) not being
> optimally implemented in Pg, but one day it could be, and at that point,
> we should use COUNT(*) - even if it's slower on older databas
Geo Carncross wrote:
> On Thu, 2005-12-15 at 17:35 +0100, Thomas Mueller wrote:
>>Geo Carncross wrote:
>>
>>>I completely agree with this. There's just the problem of databases
>>>being a moving target. Remember we talked about COUNT(*) not being
>>>optimally implemented in Pg, but one day it could
On Thu, 2005-12-15 at 17:35 +0100, Thomas Mueller wrote:
> Geo Carncross wrote:
>
> > I completely agree with this. There's just the problem of databases
> > being a moving target. Remember we talked about COUNT(*) not being
> > optimally implemented in Pg, but one day it could be, and at that poi
Geo Carncross wrote:
> On Thu, 2005-12-15 at 17:35 +0100, Thomas Mueller wrote:
> > Geo Carncross wrote:
> >
> > > I completely agree with this. There's just the problem of databases
> > > being a moving target. Remember we talked about COUNT(*) not being
> > > optimally implemented in Pg, but one
On Thu, 2005-12-15 at 09:50 -0800, Kevin Brown wrote:
> > I mean, does it apply specifically to COUNT(*)? I checked the release
> > notes and I couldn't find mention of it...
>
> If you're looking to find the total size of a table, no. In
> PostgreSQL, that's a Fundamentally Hard Problem because
On Sat, 2005-12-17 at 17:59 +0100, Thomas Mueller wrote:
> > With a mime message like this:
> >
> > --b1
> > text
> > --b1
> > rfc822
> > --b2
> > text
> > --b2--
> > --b1--
> >
> > Perhaps a parts layout similar to this:
> >
> > part,pre_boundary, content, encoding, post_boundary
> > '1', 'b1',
