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 face,
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
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 faile
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
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
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,
12 matches
Mail list logo
