Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> writes:
> Certainly decoupling presentation from storage would be nice, but even before
> that generalised use of surrogate keys seems to me a knee-jerk reaction.
I hate knee-jerk reactions too, but just think of all the pain of people
d
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
> I wonder if we should really implement file-system-cache-warmup strategy
> which we have discussed before. There are two natural good places to do
> this:
>
> (1) sequentail scan
> (2) bitmap index scan
>
For the sake of memory, there is a third place
On Sat, Jan 14, 2006 at 09:33:39PM +0100, Martijn van Oosterhout wrote:
> On Sat, Jan 14, 2006 at 11:06:07AM -0500, [EMAIL PROTECTED] wrote:
> > Not to completely defend the practice - but in some applications,
> > INSERT is much less frequent than UPDATE, and that UPDATE requires a
> > unique chec
On Sat, Jan 14, 2006 at 11:06:07AM -0500, [EMAIL PROTECTED] wrote:
> Not to completely defend the practice - but in some applications,
> INSERT is much less frequent than UPDATE, and that UPDATE requires a
> unique check on the primary key and the surrogate key, as well as an
> update, should be co
> > If the job object code is moved to the postmaster, it'll
> work when not
> > running as a service as well.
>
> I'd just as soon keep all that Windows-specific cruft in pg_ctl.
> So I think the way you've got it set up is fine.
Well, it'd all be localised to the backend/port/win32 directory
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> If the job object code is moved to the postmaster, it'll work when not
> running as a service as well.
I'd just as soon keep all that Windows-specific cruft in pg_ctl.
So I think the way you've got it set up is fine.
regards,
Naturally, just a minute after sending the patch, I realised how it can
be done better ;)
If the job object code is moved to the postmaster, it'll work when not
running as a service as well. And there's no way to break out of the job
object - it's just the other part.
Yes, I'll set up a new patc
EnterpriseDB is a clone AND a fork. :-) We work hard to free customers from Oracle vendor lock-in AND stay up with the latest releases and patches of Postgres AND don't break any Postgres native and/or ANSI functionality.
--Denis Lussier
Founder & CTO
www.EnterpriseDB.com
On 1/11/0
On 1/14/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Jaime Casanova wrote:
> > From time to time people ask me if there is a way to "customize"
> > messages for constraints so they could be more informative to the
> > user...
>
> What about this?
>
> => create table foo (fld int4 constraint "f
On Fri, Jan 13, 2006 at 12:42:55PM +, Leandro Guimarães Faria Corcete DUTRA
wrote:
> Rod Taylor rbt.ca> writes:
> > The basic idea is that most of us break out schemas by creating fake
> > primary keys for the purpose of obtaining performance because using the
> > proper primary key (single o
Rod Taylor wrote:
If you still declare the natural key(s) as UNIQUEs, you have just made
performance worse. Now there are two keys to be checked on UPDATEs and
INSERTs, two indexes to be updated, and probably a SEQUENCE too.
Indeed. Using a surrogate key is not free and that is why it would
On Fri, 2006-01-13 at 12:42 +, Leandro Guimarães Faria Corcete DUTRA
wrote:
> Rod Taylor rbt.ca> writes:
>
> > The basic idea is that most of us break out schemas by creating fake
> > primary keys for the purpose of obtaining performance because using the
> > proper primary key (single or mul
Michael Glaesemann wrote:
On Jan 13, 2006, at 21:42 , Leandro Guimarães Faria Corcete DUTRA wrote:
If you still declare the natural key(s) as UNIQUEs, you have just made
performance worse. Now there are two keys to be checked on UPDATEs and
INSERTs, two indexes to be updated, and probably a S
On Jan 13, 2006, at 21:42 , Leandro Guimarães Faria Corcete DUTRA wrote:
If you still declare the natural key(s) as UNIQUEs, you have just made
performance worse. Now there are two keys to be checked on UPDATEs
and
INSERTs, two indexes to be updated, and probably a SEQUENCE too.
For UPDAT
Rod Taylor rbt.ca> writes:
> The basic idea is that most of us break out schemas by creating fake
> primary keys for the purpose of obtaining performance because using the
> proper primary key (single or multiple columns) is often very slow.
This is one thing I simply can't understand.
If you s
Jaime Casanova wrote:
> From time to time people ask me if there is a way to "customize"
> messages for constraints so they could be more informative to the
> user...
What about this?
=> create table foo (fld int4 constraint "fld must contain positive numbers"
check (fld > 0));
CREATE TABLE
=> i
16 matches
Mail list logo
