. I will surely follow the advice as soon as
the load starts to grow. For now catching the table not found
exception within the insert trigger and creating the table on the fly
seems a good balance between performance and ease of use.
Cheers
--
Matteo Beccati
Development Consulting - http
that, but
I thought it was better to report that anyway, just in case.
Cheers
--
Matteo Beccati
Development Consulting - http://www.beccati.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
TABLE
I'm not sure if the two failures are related in some way, but I thought
it was good to report them both anyway.
Cheers
--
Matteo Beccati
Development Consulting - http://www.beccati.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
On 29/01/2012 22:33, Tom Lane wrote:
Matteo Beccati p...@beccati.com writes:
I've just noticed that an expression index I've created was not used with a
view contiaining a UNION ALL. Switching to UNION or querying the table
directly works as expected.
Looks like I broke this back
On 29/01/2012 16:06, p...@beccati.com wrote:
The following bug has been logged on the website:
Bug reference: 6416
Logged by: Matteo Beccati
Email address: p...@beccati.com
PostgreSQL version: 9.1.2
Operating system: Debian Sqeeze
Description:
I've just
.
Agreed, there's no need to unpack here. Fixed, thanks for the report!
Just to clarify, am I correct assuming that the issue does not affect
tables which have non-indexed inet fields?
Cheers
--
Matteo Beccati
Development Consulting - http://www.beccati.com/
--
Sent via pgsql-bugs mailing
The following bug has been logged online:
Bug reference: 5255
Logged by: Matteo Beccati
Email address: p...@beccati.com
PostgreSQL version: 8.5alpha3
Operating system: NetBSD 5.0.1
Description:COUNT(*) returns wrong result with LEFT JOIN
Details:
Discovered
Il 25/12/2009 18:13, Tom Lane ha scritto:
I wrote:
I guess we missed something about when it's safe to do this optimization.
I've applied the attached patch to fix this.
Thanks. Everything's working fine now!
Merry Xmas
--
Matteo Beccati
Development Consulting - http://www.beccati.com
type definition were exactly
the same (i.e. varchar(64)). I can live with it, but I suppose this fix
might be related to the varlen one.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
