On Fri, Jan 27, 2006 at 08:23:55PM -0500, Mike Biamonte wrote:
> This query took 18 hours on PG 8.1 on a Dual Xeon, RHEL3, (2.4
> Kernel) with RAID-10 (15K drives) and 12 GB Ram. I was expecting it
> to take about 4 hours - based on some experience with a similar
> dataset on a different machine
On Sat, Jan 14, 2006 at 09:37:01PM -0500, Charles Sprickman wrote:
> Following up to myself again...
>
> On Wed, 14 Dec 2005, Charles Sprickman wrote:
>
> >Hello all,
> >
> >Supermicro 1U w/SCA backplane and 4 bays
> >2x2.8 GHz Xeons
> >Adaptec 2015S "zero channel" RAID card
>
> I don't want to
On Wed, Mar 30, 2005 at 08:41:43PM -0600, John Arbash Meinel wrote:
> If all you are doing is append only logging, the fastest thing is
> probably just a flat file. You could have something that comes along
> later to move it into the database. It doesn't really sound like you are
> using any featu
On Wed, Feb 23, 2005 at 02:15:52PM -0500, John Allgood wrote:
> using custom scripts. Maybe I have given a better explanation of the
> application. my biggest concern is how to partition the shared storage
> for maximum performance. Is there a real benifit to having more that one
> raid5 partiti
On Wed, Feb 23, 2005 at 11:39:27AM -0500, John Allgood wrote:
> Hello All
>
>I am setting up a hardware clustering solution. My hardware is Dual
> Opteron 550 with 8GB ram. My external storage is a Kingston Fibre
> channel Infostation. With 14 15000'k 36GB drives. The OS we are running
> is
On Sun, Jan 02, 2005 at 09:54:32AM +0700, [EMAIL PROTECTED] wrote:
> postgresql 7.3.2-1 with RH 9 on a mechine of 2 Xeon 3.0 Ghz and ram of 4 Gb.
You may want to try disabling hyperthreading, if you don't mind
rebooting.
> grew up to 3.5 Gb and there were more than 160 concurent connections.
Lo
On Mon, Dec 20, 2004 at 03:17:11PM +1100, Theo Galanakis wrote:
> Under postgres 7.3 logging is incredibly slow!
>
> I have applied the following settings:
>
> syslog = 2
> syslog_facility = 'LOCAL0'
> syslog_ident = 'postgres'
>
> log_connections = true
> log_duration = true
> log_pid =
On Wed, Nov 17, 2004 at 09:13:09AM -0800, Darcy Buskermolen wrote:
> On November 16, 2004 08:00 pm, Michael Adler wrote:
> > http://pugs.postgresql.org/sfpug/archives/21.html
> >
> > I noticed that some of you left coasters were talking about memcached
> > and pgsq
http://pugs.postgresql.org/sfpug/archives/21.html
I noticed that some of you left coasters were talking about memcached
and pgsql. I'm curious to know what was discussed.
In reading about memcached, it seems that many people are using it to
circumvent the scalability problems of MySQL (lack o
On Thu, Oct 07, 2004 at 11:48:41AM -0400, Bill Montgomery wrote:
> Alan Stange wrote:
>
> The same test on a Dell PowerEdge 1750, Dual Xeon 3.2 GHz, 512k cache,
> HT on, Linux 2.4.21-20.ELsmp (RHEL 3), 4GB memory, pg 7.4.5:
>
> Far less performance that the Dual Opterons with a low number of
>
On Thu, Sep 30, 2004 at 09:45:51AM -0400, Merlin Moncure wrote:
> Now, if the same query is executed as a prepared statement,
> prepare ps(...) as select f(t.c) from t where [expr] limit 1;
> execute ps;
>
> now, if ps ends up using a index scan on t, everything is ok. However,
> if ps does a seq
On Thu, Sep 23, 2004 at 09:23:51PM -0400, Jason Coene wrote:
> I ran some previous queries to get pgpool to pre-establish all the
> connections, and ab ran for a few minutes (with one query per page, eek!).
> It was still exhibiting the same problems as before. While so many new
> connections at o
On Wed, Aug 04, 2004 at 03:49:11AM +, Martin Foster wrote:
> Also note that some of these scripts run for longer durations even if
> they are web based.Some run as long as 30 minutes, making queries to
> the database from periods of wait from five seconds to twenty-five
> seconds. Un
On Fri, Jul 23, 2004 at 03:20:54PM +0930, William Carney wrote:
> But with the server running on one machine and the client running on
> another, the two machines being connected by a 100 Mb ethernet, with nothing
> else on the network, this test takes 17 minutes to run. I have tried
> changing th
On Thu, Mar 18, 2004 at 03:39:12PM -0500, Tom Lane wrote:
> Michael Adler <[EMAIL PROTECTED]> writes:
> > In porting an application from v7.2 and v7.3, I noticed that a join on a varchar
> > column and a text column was ignoring indices that were helpful in v7.2. When I
&g
In porting an application from v7.2 and v7.3, I noticed that a join on a varchar
column and a text column was ignoring indices that were helpful in v7.2. When I
explicitly cast the text to a varchar (or set ENABLE_SEQSCAN TO false) the index is
scanned and it works as efficiently as in v7.2.
On Wed, 17 Sep 2003, Tom Lane wrote:
> Michael Adler <[EMAIL PROTECTED]> writes:
> > I have been experimenting with a new Seagate Cheetah 10k-RPM SCSI to
> > compare with a cheaper Seagate Barracuda 7200-RPM IDE (each in a
> > single-drive configuration). The Cheet
I have been experimenting with a new Seagate Cheetah 10k-RPM SCSI to
compare with a cheaper Seagate Barracuda 7200-RPM IDE (each in a
single-drive configuration). The Cheetah definately dominates the generic
IO tests such as bonnie++, but fares poorly with pgbench (and other
postgresql operations)
18 matches
Mail list logo
