Re: [PERFORM] database tuning

2007-12-10 Thread Richard Huxton
kelvan wrote: ok heres the thing i dont have a choice i just have to work with whats given Ah well, it happens to all of us. whether it is good or not why i need these overheads is for block calculations and and tablespace calculations i have to keep everything in a very very small area on

Re: [PERFORM] Utilizing multiple cores for one query

2007-12-10 Thread Marko Kreen
On 12/1/07, Jonah H. Harris [EMAIL PROTECTED] wrote: Currently, the only way to parallelize a query in Postgres is to use pgpool-II. FYI: plproxy issues queries for several nodes in parallel too. -- marko ---(end of broadcast)--- TIP 6:

[PERFORM] Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.

2007-12-10 Thread Piotr Gasidło
Hello, I've created table: quaker= \d users Table public.users Column | Type| Modifiers ---+---+ id| integer | not null default

Re: [PERFORM] Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.

2007-12-10 Thread Richard Huxton
Piotr Gasidło wrote: Some performance loss, but OK. Now I've changed = into LIKE to use users_user_name_unique_text_pattern_ops index and rerun query: explain analyze select user_login('quaker'); QUERY PLAN

Re: [PERFORM] Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.

2007-12-10 Thread Pavel Stehule
Hello this is known problem of prepared statements. Prepared statement has plan built without knowledge any values and should not be optimal. try use dynamic query and statement EXECUTE INTO Regards Pavel Stehule On 10/12/2007, Piotr Gasidło [EMAIL PROTECTED] wrote: Hello, I've created

Re: [PERFORM] database tuning

2007-12-10 Thread Scott Marlowe
On Dec 7, 2007 1:13 PM, kelvan [EMAIL PROTECTED] wrote: ok heres the thing i dont have a choice i just have to work with whats given whether it is good or not why i need these overheads is for block calculations and and tablespace calculations i have to keep everything in a very very small

Re: [PERFORM] database tuning

2007-12-10 Thread kelvan
Scott Marlowe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Dec 7, 2007 1:13 PM, kelvan [EMAIL PROTECTED] wrote: ok heres the thing i dont have a choice i just have to work with whats given whether it is good or not why i need these overheads is for block calculations and

Re: [PERFORM] database tuning

2007-12-10 Thread Kevin Grittner
On Mon, Dec 10, 2007 at 6:29 PM, in message [EMAIL PROTECTED], kelvan [EMAIL PROTECTED] wrote: i need a more powerful dbms one that can handle multi threading. If you're looking to handle a lot of concurrent users, PostgreSQL has the power. The threading issues really only impact the

Fwd: Re: [PERFORM] database tuning

2007-12-10 Thread Kevin Grittner
On Mon, Dec 10, 2007 at 6:15 PM, in message [EMAIL PROTECTED], Kevin Grittner wrote: with 6 MB of RAM Obviously a typo -- that should read 6 GB of RAM. ---(end of broadcast)--- TIP 4: Have you searched our list archives?

Re: [PERFORM] database tuning

2007-12-10 Thread Greg Smith
On Tue, 11 Dec 2007, kelvan wrote: i am going to blow up that mac and burn postgres as i need a more powerful dbms one that can handle multi threading. Someone pointed this out already, but I'll repeat: PostgreSQL has a multi-process architecture that's fully capable of taking advantage of

[PERFORM] libgcc double-free, backend won't die

2007-12-10 Thread Craig James
This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serverlog gets this message: *** glibc detected *** postgres: mydb mydb