Re: [PERFORM] How to revoke a password

2005-07-08 Thread Michael Fuhr
On Fri, Jul 08, 2005 at 05:16:27PM -0700, Bailey, Larry wrote: > > Thanks but it is still prompting for a password. Let's back up a bit: what problem are you trying to solve? Do you want the user to be able to log in without entering a password? If so then see "Client Authentication" in the doc

Re: [PERFORM] How to revoke a password

2005-07-08 Thread Joshua D. Drake
Bailey, Larry wrote: Thanks but it is still prompting for a password. Does your pg_hba.conf require a password? Sincerely, Joshua D. Drake Larry Bailey Sr. Oracle DBA First American Real Estate Solution (714) 701-3347 [EMAIL PROTECTED] -Original Message- From: Joshua D. Drake [m

Re: [PERFORM] How to revoke a password

2005-07-08 Thread Bailey, Larry
Thanks but it is still prompting for a password. Larry Bailey Sr. Oracle DBA First American Real Estate Solution (714) 701-3347 [EMAIL PROTECTED] -Original Message- From: Joshua D. Drake [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 5:10 PM To: Bailey, Larry Cc: pgsql-performan

Re: [PERFORM] How to revoke a password

2005-07-08 Thread Alvaro Herrera
On Fri, Jul 08, 2005 at 05:09:48PM -0700, Joshua D. Drake wrote: > Bailey, Larry wrote: > >I created a user with a password. That newly created user now have > >tables and indexes. I want to ALTER that user to exclude the password. > >How is this accomplished without dropping and recreating the use

Re: [PERFORM] How to revoke a password

2005-07-08 Thread Joshua D. Drake
Bailey, Larry wrote: I created a user with a password. That newly created user now have tables and indexes. I want to ALTER that user to exclude the password. How is this accomplished without dropping and recreating the users? Never tried to go backwards before but: alter user foo with encrypt

[PERFORM] How to revoke a password

2005-07-08 Thread Bailey, Larry
I created a user with a password. That newly created user now have tables and indexes. I want to ALTER that user to exclude the password. How is this accomplished without dropping and recreating the users? Larry Bailey Sr. Oracle DBA First American Real Estate Solution (714) 701-3347 [EMAIL PROTEC

Re: [PERFORM] Select performance vs. mssql

2005-07-08 Thread Jochem van Dieten
Enrico Weigelt wrote: Bruno Wolff III wrote: This gets brought up a lot. The problem is that the index doesn't include information about whether the current transaction can see the referenced row. Putting this information in the index will add significant overhead to every update and the opinio

Re: [PERFORM] Mount database on RAM disk?

2005-07-08 Thread Merlin Moncure
> Stuart, > > > I'm putting together a road map on how our systems can scale as our load > > increases. As part of this, I need to look into setting up some fast > > read only mirrors of our database. We should have more than enough RAM > > to fit everything into memory. I would like to find out i

Re: [PERFORM] cost-based vacuum

2005-07-08 Thread Tom Lane
Ian Westmacott <[EMAIL PROTECTED]> writes: > If I make the single configuration change of setting > vacuum_cost_delay=1000, each iteration in analyze_thread takes > much longer, of course. But what I also see is that the CPU > usage of the connections for writer_thread and reader_thread > spike up

Re: [PERFORM] Mount database on RAM disk?

2005-07-08 Thread Josh Berkus
Stuart, > I'm putting together a road map on how our systems can scale as our load > increases. As part of this, I need to look into setting up some fast > read only mirrors of our database. We should have more than enough RAM > to fit everything into memory. I would like to find out if I could >

Re: [PERFORM] Why the planner is not using the INDEX .

2005-07-08 Thread Enrico Weigelt
* David Gagnon <[EMAIL PROTECTED]> wrote: > FOR inventoryTransaction IN >SELECT DISTINCT IRNUM, IRAENUM, IRSTATUT, IRSENS, IRSOURCE, > IRDATE, IRQTE >FROM IR >WHERE IRNUM = ANY (requestIds) and IRYPNUM = companyId >LOOP hmm. you probably could create the query dynamic

[PERFORM] cost-based vacuum

2005-07-08 Thread Ian Westmacott
I am beginning to look at Postgres 8, and am particularly interested in cost-based vacuum/analyze. I'm hoping someone can shed some light on the behavior I am seeing. Suppose there are three threads: writer_thread every 1/15 second do BEGIN TRANSACTION COPY table1 FROM stdin ..

Re: [PERFORM] Need help to decide Mysql vs Postgres

2005-07-08 Thread Moises Alberto Lindo Gutarra
Linux(Debian) + Java + PostgreSQL = Fastest 2005/7/8, Mark Lewis <[EMAIL PROTECTED]>: > On Fri, 2005-07-08 at 16:43 +0200, Enrico Weigelt wrote: > > * PFC <[EMAIL PROTECTED]> wrote: > > > > > > > For Python it's the reverse : the MySQL driver is slow and dumb, > > > and the postgres driv

Re: [PERFORM] Need help to decide Mysql vs Postgres

2005-07-08 Thread Mark Lewis
On Fri, 2005-07-08 at 16:43 +0200, Enrico Weigelt wrote: > * PFC <[EMAIL PROTECTED]> wrote: > > > > For Python it's the reverse : the MySQL driver is slow and dumb, > > and the postgres driver (psycopg 2) is super fast, handles all > > quoting, > > and knows about type conversions, i

Re: [PERFORM] Need help to decide Mysql vs Postgres

2005-07-08 Thread Enrico Weigelt
* PFC <[EMAIL PROTECTED]> wrote: > For Python it's the reverse : the MySQL driver is slow and dumb, > and the postgres driver (psycopg 2) is super fast, handles all > quoting, > and knows about type conversions, it will automatically convert a > Python List into a postgres Arra

Re: [PERFORM] Select performance vs. mssql

2005-07-08 Thread Enrico Weigelt
* Bruno Wolff III <[EMAIL PROTECTED]> wrote: > This gets brought up a lot. The problem is that the index doesn't include > information about whether the current transaction can see the referenced > row. Putting this information in the index will add significant overhead > to every update and the

Re: [PERFORM] plain inserts and deletes very slow

2005-07-08 Thread Enrico Weigelt
* Klint Gore <[EMAIL PROTECTED]> wrote: > Turn on statement logging. I've seen delphi interfaces do extra queries > on system tables to find some structure information. I'm already using statement logging of all queries taking longer than 200ms. It seems that only the INSERT takes such a time.

Re: [PERFORM] Mount database on RAM disk?

2005-07-08 Thread Rod Taylor
> If I could get and deploy some SSD (Solid State Disk) devices that > would make this sort of thing *actually safe,* I'd expect that to be a > pretty fabulous improvement, at least for write-heavy database > activity. Not nearly as much as you would expect. For the price of the SSD and a SCSI con