Simon Riggs wrote:
> If my assumption is badly wrong on that then perhaps HOT would not be
> useful after all. If we find that the majority of UPDATEs meet the HOT
> pre-conditions, then I would continue to advocate it.
This is exactly my situation. All updated hit non-indexed fields, with a
lot o
I wrote:
[moving to -hackers]
I wrote:
I have made some progress with what I think is needed to have two
interpreters for plperl. This is a lot harder than the pltcl case
for two reasons: 1. there are no restrictions on having 2 tcl
interpreters, and 2. tcl does not need to save and rest
> Are you familiar with the contrib/ian module that will be in 8.2?
>
> --
> Michael Fuhr
I develepped this code on 8.0.x version, for my work, but I can always study :)
Enrico
--
If Bill Gates had a penny for everytime Windows crashed,he'd be a
multi-billionaire by now ...oh look, he a
On Mon, 13 Nov 2006 10:20:38 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> This could be a piece of wheel reinvention. Please see
> http://pgfoundry.org/projects/gtin/
I didn't know this project, I arrived later... :(
Thanks
Enrico
--
If Bill Gates had a penny for everytime Windows crashed
Enrico wrote:
I'm writing a little contrib for postgresql,
to handle ean barcode datatype.
It contains operators and functions like ISBN datatype,
and it also contains a check digit function to
control right or wrong inserts.
Can this code is useful for postgresql community?
Now, I'm testing
On Mon, Nov 13, 2006 at 04:05:08PM +0100, Enrico wrote:
> I'm writing a little contrib for postgresql,
> to handle ean barcode datatype.
>
> It contains operators and functions like ISBN datatype,
> and it also contains a check digit function to
> control right or wrong inserts.
>
> Can this cod
I'm writing a little contrib for postgresql,
to handle ean barcode datatype.
It contains operators and functions like ISBN datatype,
and it also contains a check digit function to
control right or wrong inserts.
Can this code is useful for postgresql community?
Now, I'm testing my code on EAN 1
[snip]
> IMHO *most* UPDATEs occur on non-indexed fields. [snip]
>
> If my assumption is badly wrong on that then perhaps HOT would not be
> useful after all. If we find that the majority of UPDATEs meet the HOT
> pre-conditions, then I would continue to advocate it.
Just to confirm that the scen
On Sun, 2006-11-12 at 18:31 -0500, Robert Treat wrote:
> if your not updating all of the indexes on a table (which isn't
> likely) you're going to be better off with HOT
Do you mean *any* rather than all?
> (which isn't likely)
There is no chance involved, unless the DBA adding indexes is unaw
Robert Treat wrote:
While I don't disagree that this is an important feature, the fact that it is
being designed with pgadmin specific backwards compatability (for example the
functions that rename core functions) leaves me dubious as to it being a more
general solution. Because of that I woul
10 matches
Mail list logo
