Re: [PERFORM] [GENERAL] Performance hit of foreign key constraints?

2003-07-23 Thread Shridhar Daithankar
On 23 Jul 2003 at 16:05, Jean-Christian Imbeault wrote: I have a database which is constantly being written to. A web server's log file (and extras) is being written to it. There are no deletions or updates (at least I think so :). As the web traffic increases so will the write intensity.

Re: [PERFORM] factoring problem with view in 7.3.3

2003-07-23 Thread Richard Huxton
On Wednesday 23 July 2003 11:21, Rajesh Kumar Mallah wrote: Hi , I have a view which is a union of select of certain feilds from indentical tables. The problem is when we query a column on which index exists exists foreach of the tables does not use the indexes. But when we query

[PERFORM] different query plan for same select

2003-07-23 Thread Jörg Schulz
I have these two tables with the same data on two different machines (SuSE 8.2 and Gentoo both with 7.3.2): schulz= \d rechnung Table jschulz.rechnung Column | Type | Modifiers +--+--- system | smallint | not null jahr |

Re: [PERFORM] factoring problem with view in 7.3.3 [ PARTIALLY SOLVED ]

2003-07-23 Thread mallah
Rajesh Kumar Mallah [EMAIL PROTECTED] writes: I have a view which is a union of select of certain feilds from indentical tables. The problem is when we query a column on which index exists exists foreach of the tables does not use the indexes. Hard to be certain since you didn't show us the

Re: [PERFORM] factoring problem with view in 7.3.3 [ PARTIALLY SOLVED ]

2003-07-23 Thread Tom Lane
[EMAIL PROTECTED] writes: the column 'generated' was timestamp in 2 place and date in 2 place, i wanted it in my and did a typecasting in the view below but it suffers from the same problem . AFAIR it should work if you insert casts into the UNION's member selects. Maybe you didn't get the

Re: [PERFORM] slow table updates

2003-07-23 Thread Reece Hart
Richard- Thanks for the suggestions. I too had thought about the FK checks, even though the columns aren't getting updated. I'm flabbergasted that the update is still running (~22 hours elapsed). By comparison, the database takes only 4 hours to recreate from backup! Something funny is

Re: [PERFORM] slow table updates

2003-07-23 Thread Reece Hart
On Wed, 2003-07-23 at 10:47, Guthrie, Jeremy wrote: Have you checked the sizes of your indexes? You may need to rebuild them... Multiply the relpages colum by 8192. So, what does this tell me? I'm guessing that you're implying that I should expect 8192 keys per page, and that this

Re: [PERFORM] slow table updates

2003-07-23 Thread Guthrie, Jeremy
Look at it like this(this is how this affected me): I had a table that use to be the primary home for my data(6 gigs worth). I copied out and copied to another table. I purged and then I 'vacuum full''d the database. After a day things really started going to hell. SLOOOW.. like 30 minutes