Re: [PERFORM] deferred foreign keys

One more question: does the FK checker know to skip checking a constraint if the column in question did not change during an update? That is, if I have a user table that references an owner_id in an owners table as a foreign key, but I update fields other than owner_id in the user table, will it st

Re: [PERFORM] "fun with multipart primary keys" hobby kit

Actually, it would appear that I was born yesterday. I had no idea. Added the cast and it fell right in. Thanks! chris <-- feeling pretty dumb right now On Sat, 2004-01-03 at 00:57, Tom Lane wrote: > Chris Trawick <[EMAIL PROTECTED]> writes: > > contactid | bigint | not null >

Re: [PERFORM] "fun with multipart primary keys" hobby kit

Chris Trawick <[EMAIL PROTECTED]> writes: > contactid | bigint | not null ^^ > Am I reading this right? Is it only using half of the fully-qualified > pk index? How do I diagnose this? Has anyone seen this before? Surely you've been around here long enough to rem

[PERFORM] "fun with multipart primary keys" hobby kit

I tried searching the archives to find something like this. The search function doesn't like me much, and believe me the feeling is mutual. So I'm forced to pollute your inboxes with yet another "why the hell isn't this thing using my index" email. I apologize in advance. I have a many-to-many

Re: [PERFORM] Tuning Techniques To Avoid?

Christopher Browne <[EMAIL PROTECTED]> writes: > Here's a scheme for query optimization that probably needs to be > avoided in that it would run afoul of a patent held by Oracle... What does this have to do with Hervé Piedvache's post "Why memory is not used?" ? -- greg -

Re: [PERFORM] Why memory is not used ? Why vacuum so slow ?

Hi Tom, Le Vendredi 2 Janvier 2004 15:42, Tom Lane a écrit : > =?iso-8859-15?q?Herv=E9=20Piedvache?= <[EMAIL PROTECTED]> writes: > > Second point ... after importing my dump ... I make a vacuum full analyze > > of my base (in same time because of my caculation of the day before for > > my aggregat

Re: [PERFORM] Why memory is not used ? Why vacuum so slow ?

=?iso-8859-15?q?Herv=E9=20Piedvache?= <[EMAIL PROTECTED]> writes: > and I have also saw that the full vacuum for pg_atribute seems > to be so slow ... more than 1 min for 7256 tupples ? Is this is normal ? > INFO: --Relation pg_catalog.pg_attribute-- > INFO: Pages 119: Changed 0, reaped 1, Empt

Re: [PERFORM] Very slow update + not using clustered index

Mike Glover <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> wrote: >> It seems unlikely that the raw row inserts and updating the single >> index could be quite that slow --- perhaps you have a foreign key >> or trigger performance problem? >There are no foreign keys or triggers for

Re: [PERFORM] Why memory is not used ? Why vacuum so slow ?

=?iso-8859-15?q?Herv=E9=20Piedvache?= <[EMAIL PROTECTED]> writes: > Second point ... after importing my dump ... I make a vacuum full analyze of > my base (in same time because of my caculation of the day before for my > aggregats and stats tables about 200 000 row deleted and/or inserted for mor

[PERFORM] Tuning Techniques To Avoid?

Here's a scheme for query optimization that probably needs to be avoided in that it would run afoul of a patent held by Oracle... It look

[PERFORM] Why memory is not used ? Why vacuum so slow ?

Hi, I have tried to tune a database that I'm using only for statistical access ... I mean that I'm importing a dump of my production database each night, but preserving some aggregat tables, and statistics ones ... (that I'm calculating after the importation of the dump). This database is only