> We have a development server running
>
> OS - Linux development-server 2.4.20-openmosix-r4 #1 SMP Mon May 19
02:32:52
> PDT 2003 i686 Intel(R) Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux
>
> Database - PostgreSQL 7.3 on i686-pc-linux-gnu, compiled by GCC gcc
(GCC)
> 3.2.1
>
> We have a table ctce
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. P
On Fri, 2003-09-19 at 07:38, Michael Meskes wrote:
> I included strndup because some systems didn't seem to have it. Any idea
> what else I could do? Okay, I could rename it and use only the renamed
> function as it's just used internally.
>
> What surprises me is that it compiles fine for me desp
Christoph,
Thx for your response. We didn't change the search_parth variable. Moreover,
I tried all combination of drop statements like
Drop table table_name
Drop table owner.table_name
Drop table "table_name"
Drop table "owner.table_name"
I don't know what is the problem. Somebody in this esteem
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 17 Sep 2003, Tom Lane wrote:
>> I think we have two choices: disallow foreign-key references from temp
>> tables to permanent tables, or take out the optimization of storing
>> temp table pages in private memory.
> I think the first is probably b
I've noticed that postgres strace output contains long groups of
setitimer/semop/setitimer.
Just FYI: semtimedop is a special syscalls that implements a semop with
a timeout. It was added just for the purpose of avoiding the setitimer
calls.
I know that it's supported by Solaris and recent Linux
Neil Conway <[EMAIL PROTECTED]> writes:
> - Invent a new set of lmgr locks; call them "right of insertion" locks,
> and have one for each bucket in the hash index. Only one backend will
> hold the ROI lock for a given bucket at any given time.
Rather than trying to invent a new set of lock IDs (wh
Hello,
I just read a rather disturbing post
PostgreSQL does not support read uncommited and repeatable read
isolation levels? If that is so... then PostgreSQL is NOT ACID compliant?
What is the real deal on this?
Sincerley,
Joshua Drake
--
Command Prompt, Inc., home of Mammoth Postgre
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> The select take long:
> Postgres7.3.3: average 4000 ms
> Postgres7.4b2: average 2600 ms
> you can experiment your self with the dump that I gave you
Hm. I tried to duplicate your results. I'm getting about 5400 msec
versus 4200 msec, which is a nic
On Fri, 19 Sep 2003, Joshua D. Drake wrote:
> Hello,
>
> I just read a rather disturbing post
>
> PostgreSQL does not support read uncommited and repeatable read
> isolation levels? If that is so... then PostgreSQL is NOT ACID compliant?
>
> What is the real deal on this?
Postgresql
Manfred Spraul <[EMAIL PROTECTED]> writes:
> I've noticed that postgres strace output contains long groups of
> setitimer/semop/setitimer.
> Just FYI: semtimedop is a special syscalls that implements a semop with
> a timeout. It was added just for the purpose of avoiding the setitimer
> calls.
>
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I just read a rather disturbing post
> PostgreSQL does not support read uncommited and repeatable read
> isolation levels? If that is so... then PostgreSQL is NOT ACID compliant?
Why do you find that disturbing? Read uncommitted is the ver
Hello,
Sorry guys I made the unbelievable mistake of talking on the #mysql
channel today. Can you believe that they
actually feel that the fact that you can insert data outside the
boundaries of the data type (int for example) and
mySQL won't throw an exception is still valid ACID compliance.
On Fri, 19 Sep 2003, Joshua D. Drake wrote:
> Hello,
>
> Sorry guys I made the unbelievable mistake of talking on the #mysql
> channel today. Can you believe that they
> actually feel that the fact that you can insert data outside the
> boundaries of the data type (int for example) and
> mySQL
Hello,
It wasn't so much that I believed them, as that I spent an hour
digging through PDF's written by guys who look like RMS trying to find
the answer to a yes or no question. Are you aware that these guys don't
believe in a yes or no question? There is always "conditions". I am feeling
much
It's funny timing - I had to prepare a comparison between PostgreSQL and
MySQL recently, explaining why we would prefer PostgreSQL. I know some
people here have issues with the MySQL crashme test results, but I have to
say I found it possibly one of the best postgreSQL advertisements
available.
Hello,
Actually if you really want to scare them.
1. Use Innodb
2. Create 5000 inserts with at least 5k of data. The table needs to have
a primary key.
3. Insert the 5000 records for 50 connections (250,000 inserts).
4. Watch the deadlocks fly.
They didn't believe me. Then the guy tried it li
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] ("Joshua D.
Drake") transmitted:
> PostgreSQL does not support read uncommited and repeatable read
> isolation levels? If that is so... then PostgreSQL is NOT ACID
> compliant?
Are you certain that the source of the informati
[I'm not convinced this is a -hackers issue so have cross posted to -general in
the expectation followups will go there]
I also didn't feel there was much I could cut from the earlier posts without
losing relevent info, so I didn't. Sorry.
On Fri, 19 Sep 2003, chakkara rangarajan wrote:
> Chris
19 matches
Mail list logo
