On 27/04/12 09:33, Tom Lane wrote:
Toby Corkindaletoby.corkind...@strategicdata.com.au writes:
I've created a bit of a test case now.
There's a Perl script here:
http://dryft.net/postgres/
AFAICT, what is happening is that we're repeating the planning of that
messy nest of views for each
On 04/29/2012 07:19 PM, Toby Corkindale wrote:
On 27/04/12 09:33, Tom Lane wrote:
Toby Corkindaletoby.corkind...@strategicdata.com.au writes:
I've created a bit of a test case now.
There's a Perl script here:
http://dryft.net/postgres/
AFAICT, what is happening is that we're repeating the
Toby Corkindale toby.corkind...@strategicdata.com.au writes:
I'm still curious about why I can do a SELECT * FROM complexview without
using much memory, but an UPDATE foo FROM complexview causes all the
memory to get exhausted?
The former only requires the complexview to get planned once.
On 30/04/12 11:26, Rob Sargentg wrote:
On 04/29/2012 07:19 PM, Toby Corkindale wrote:
On 27/04/12 09:33, Tom Lane wrote:
Toby Corkindaletoby.corkind...@strategicdata.com.au writes:
I've created a bit of a test case now.
There's a Perl script here:
http://dryft.net/postgres/
AFAICT, what is
Hi,
From the documentation I was able to build a trigger firing upon deletion of a
record a function that delivers tablename_operation as a notification one needs
to subscribe to. So in terminal I can say LISTEN persons_delete and instantly
will receive
Asynchronous notification
