[PERFORM] ACL cleanup

This might not be 100% performance compilant but i guess its better than -hackers since these day's there seem to be some big consern :) So feel free to comment [Abstract: Underlyin plpgsql should remove all public user ACL's from Function,Table Sequence,View ... ] -elz --

Re: [PERFORM] Database possible corruption , unsolvable mystery

> Hrm, you know that you -should- upgrade to at least the latest 7.4 > (7.4.13 I think is the most recent). looking from the > changelogs, there are a few bugs that you could be hitting; > > 7.4.10 > * Fix race condition in transaction log management There > was a narrow window in which an I

Re: [PERFORM] Database possible corruption , unsolvable mystery

> -Original Message- > From: Richard Huxton [mailto:[EMAIL PROTECTED] > Sent: 29 mars 2006 17:10 > To: Eric Lauzon > Cc: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Database possible corruption , > unsolvable mystery > > Eric Lauzon wrote: > &

[PERFORM] Database possible corruption , unsolvable mystery

questions were clear. Have a good day, and thank you in advance. Eric Lauzon [Recherche & Développement] Above Sécurité / Above Security Tél : (450) 430-8166 Fax : (450) 430-1858 AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ Le présent message est à l'usage exclusif

[PERFORM] Schema vs Independant Databases, ACLS,Overhead,pg_hba.conf

Hello all, I have this small set of questions that i have been looking to ask and here it comes. Lets imagin we have a setup where we have multiple databases instances on one server, and we are starting to use more and more cross databases queries [query unions] using dblink [multiple context but

[PERFORM] (View and SQL) VS plpgsql

1() TO console WITH GRANT OPTION; --FUNCTION CALLER SELECT * from get_source_rule_level_1() AS (hits int8,src int8,bid int8,tid int4,min_time int8,max_time int8) Eric Lauzon [Recherche & Développement] Above Sécurité / Above Security Tél : (450) 430-8166 Fax : (450) 430-1858

Re: [PERFORM] PERFORMANCE ISSUE ODBC x LIBPQ C++ Application

i would take a peek at psqlodbc-8.0 drivers .. i wouldn't battle with other version you might find such as (unixodbc ones) -elz > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Merlin Moncure > Sent: 27 juin 2005 10:29 > To: grupos > Cc: pgsql-

Re: [PERFORM] Postgresql and xeon.

here and why, i would state pg 7.4.8 and kernel 2.6 with preemptive scheduler and dual xeon 3.2 ghz 6 gig of ram. Eric Lauzon [Recherche & Développement] Above Sécurité / Above Security Tél : (450) 430-8166 Fax : (450) 430-1858 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

[PERFORM] Postgresql and xeon.

found any comprehensive analysis/explanation for this matters beside people saying , stop using xeon and postgresql. Enlightment please... Eric Lauzon [Recherche & Développement] Above Sécurité / Above Security Tél : (450) 430-8166 Fax : (450) 430-1858 ---(en

[PERFORM] OID vs overall system performances on high load

would slow the insert process. Since OID seem to act as a global index mabey maintaning that index can become costy over high table load by postgresql backend. -Eric Lauzon ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands

[PERFORM] OID vs overall system performances on high load databases.

high load tables with oid enabled. Would the oid colum slow down table scan when you have over 20 millions row? Would the cost of maintaining the oid column inside thoses high load tables when there is no oid reference used for data seeking costy for postgres ressources!? Eric Lauzon