Re: why postgresql over other RDBMS - Mailing list pgsql-general

From PFC
Subject Re: why postgresql over other RDBMS
Date
Msg-id op.ttaap0q1cigqcu@apollo13
Whole thread Raw
In response to Re: why postgresql over other RDBMS  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: why postgresql over other RDBMS  (Scott Ribe <scott_ribe@killerbytes.com>)
List pgsql-general
On Sat, 02 Jun 2007 00:14:28 +0200, Ron Johnson <ron.l.johnson@cox.net>
wrote:

> On 06/01/07 16:38, PFC wrote:
>>
>>>>>     Will the synchronized seq scan patch be able to do this by
>>>>> issuing all  the CREATE INDEX commands at the same time from several
>>>>> different database  connections ?
>>>>  No, but it could someday.
>>      Actually I tested, it does it right now, albeit unconsciously (pg
>> doesn't do anything to synchronize the scans, but if you launch the
>> concurrent connections at the same time and issue all your "create
>> index" at the same time, only 1 table scan is needed). Maybe if the
>> tables were bigger, it would lose sync between the 3 concurrent scans
>> and would end up going slower. That's why I spoke about the
>> "synchronized scan" patch.
>
> How much of this, though, is from the OS's disk cache?  Or are Seq Scans
> O_DIRECT and bypass the OS cache?


    Well, the file was larger than disk cache, and I checked in vmstat's
number of actual bytes read from disks...
    Three threads read the table once, One thread reads the table 3 times.

    So it works right now, except it doesn't have (yet) the infrastructure to
keep the scans synchronized, and psql can't open several connections (yet).

pgsql-general by date:

Previous
From: "Purusothaman A"
Date:
Subject: Re: Corruption of files in PostgreSQL
Next
From: PFC
Date:
Subject: Re: multimaster