Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If these prove difficult, I'd say 24K would put us in an equivalent
position (two extra copies of the error message plus change). Even so,
I'm inclined to say that 8K is very tight.
We really only care about being able to de
James Mansion wrote:
I was wondering whether one could try to identify what might be termed
'enum tables' that exist to provide lookups.
There are perhaps three main types of table that is the target of a
foreign key lookup:
1) tables that map to program language enumerations: typically sm
"Webb Sprague" <[EMAIL PROTECTED]> writes:
> Is there a different potential hack for marking a table read-only,
> turning it on and off with a function()? In a hackish vein, use a
> trigger to enforce this, and maybe a rule that can do the
> optimization?
I think several people already have so
> ... People keep proposing variants of the idea
> that the executor should optimize updates on the basis of examining
> the query tree to see whether columns changed or not, and they're always
> wrong. You don't know what else might have been done to the row by
> BEFORE triggers.
Is there a dif
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If these prove difficult, I'd say 24K would put us in an equivalent
> position (two extra copies of the error message plus change). Even so,
> I'm inclined to say that 8K is very tight.
We really only care about being able to deliver an "out of memory
[redirected to -hackers]
Tom Lane wrote:
Another thing that needs to be looked at carefully is how much memory
write_csvlog() eats. I'm a little bit concerned about whether it will
result in infinite recursion when our backs are against the wall and
we only have the original 8K in ErrorContext
Lodewijk Voege <[EMAIL PROTECTED]> writes:
> I hacked up a patch that handles these two cases:
"Hack" is the right word. People keep proposing variants of the idea
that the executor should optimize updates on the basis of examining
the query tree to see whether columns changed or not, and they're
Andrew Dunstan wrote:
Could we achieve the same thing in a more general way by having a
per-FK tiny (say 10?) LRU cache of values checked. Then it wouldn't
only be restricted to constant expressions. Of course, then the
trigger would need to keep state, so it might well be too complex
(e.g. wh
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Could we achieve the same thing in a more general way by having a per-FK tiny
> (say 10?) LRU cache of values checked. Then it wouldn't only be restricted to
> constant expressions. Of course, then the trigger would need to keep state, so
> it might w
Gregory Stark wrote:
"Lodewijk Voege" <[EMAIL PROTECTED]> writes:
I hacked up a patch that handles these two cases:
- for such an INSERT/SELECT, check constant FKs only once.
This sounds like a clever idea. It seems the abstraction violation is worth it
to me.
Could we achiev
"Lodewijk Voege" <[EMAIL PROTECTED]> writes:
> I hacked up a patch that handles these two cases:
> - for such an INSERT/SELECT, check constant FKs only once.
This sounds like a clever idea. It seems the abstraction violation is worth it
to me.
> - for an INSERT/SELECT from/to the same table,
11 matches
Mail list logo