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 [l
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
>>> 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?
>>> 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 imp
""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
>> c
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 sma
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 create
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
-
Hello,
I've created table:
quaker=> \d users
Table "public.users"
Column | Type| Modifiers
---+---+
id| integer | not null defau
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: exp
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 t
11 matches
Mail list logo
