On 19-aug-2007, at 12:38, Tom Lane wrote:
An additional problem with your proposal is that it fails to consider
other changes that might be happening concurrently -- eg, what if some
other backend deletes a source row after you copy it, and commits
before
you do?
then the patch indeed
Lodewijk Vöge escribió:
On 19-aug-2007, at 12:38, Tom Lane wrote:
An additional problem with your proposal is that it fails to consider
other changes that might be happening concurrently -- eg, what if some
other backend deletes a source row after you copy it, and commits before
you do?
On 21-aug-2007, at 10:55, Alvaro Herrera wrote:
It might go in if it's correct. If you have an answer to all the
objections then there's no reason not to include it. But I must
admit I
didn't understand what was your answer to the above objection; care to
rephrase?
sorry, egg on my
On 19-aug-2007, at 12:38, Tom Lane wrote:
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
always
wrong. You don't know what else might
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
... 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
hello,
I'm working on an application that once in a while needs to shuffle some data
around with a query like:
INSERT INTO foo (some_field, bar_FK, baz_FK)
SELECT some_field,
12345 AS bar_FK,
baz_FK
FROM foo
WHERE bar_FK=123
ie. copy a block of data from a table into
13 matches
Mail list logo
