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, don't
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 achieve
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 well be
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.
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
[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
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
... 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
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 something
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
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
11 matches
Mail list logo
