"Tom Lane" <[EMAIL PROTECTED]> writes:
> This rule works for all the locales I have installed ... but I don't
> have any Far Eastern locales installed. Also, my test cases are only
> covering ASCII characters, and I believe many locales have some non-ASCII
> letters that sort after 'Z'. I'm not
* Scott Marlowe:
> If the right two disks fail in a RAID-10 you lose everything.
> Admittedly, that's a pretty remote possibility,
It's not, unless you carefully layout the RAID-1 subunits so that
their drives aren't physically adjacent. 8-/ I don't think many
controllers support that.
--
Flori
On Nov 9, 2007 7:06 AM, Ivan Voras <[EMAIL PROTECTED]> wrote:
> I just read this document and thought I should share it with this list:
>
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
Nice presentation. Thanks for posting it on here.
> Among other things (FreeBSD advocacy, mostly :
Hi,
I just read this document and thought I should share it with this list:
http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
Among other things (FreeBSD advocacy, mostly :) ), it contains a direct
comparison between MySQL and PostgreSQL on various platforms, with
PostgreSQL winning!
--
>
> Among other things (FreeBSD advocacy, mostly :) ), it contains a direct
> comparison between MySQL and PostgreSQL on various platforms, with
> PostgreSQL winning!
>
Hello,
If the queries are complex, this is understable. I had a performance
review of a Hibernate project (Java Object Relati
On Nov 9, 2007, at 6:06 AM, Ivan Voras wrote:
Hi,
I just read this document and thought I should share it with this
list:
http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
Among other things (FreeBSD advocacy, mostly :) ), it contains a
direct
comparison between MySQL and Postgr
On Nov 9, 2007 9:41 AM, Sebastian Hennebrueder <[EMAIL PROTECTED]> wrote:
> If the queries are complex, this is understable. I had a performance
> review of a Hibernate project (Java Object Relation Mapping) using
> MySQL. ORM produces easily "complex" queries with joins and subqueries.
> MySQL use
Apart from the disks, you might also investigate using Opterons instead
of Xeons. there appears to be some significant dent in performance
between Opteron and Xeon. Xeons appear to spend more time in passing
around ownership of memory cache lines in case of a spinlock.
It's not yet clear whether or
On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote:
If the queries are complex, this is understable.
The queries used for this comparison are trivial. There's only one table
involved and there are no joins. It's testing very low-level aspects of
performance.
--
* Greg Smith [EMAIL PROTECTE
Gregory Stark <[EMAIL PROTECTED]> writes:
> Could we not use the bogus range to calculate the histogram estimate
> but apply the LIKE pattern directly to the most-frequent-values
> instead of applying the bogus range? Or would that be too much code
> re-organization for now?
We have already done t
On Nov 9, 2007 5:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> he's got no MCVs, presumably because the field
> is unique.
It is. The ancestors field contains the current folder itself so the
id of the folder (which is the primary key) is in it.
--
Guillaume
---(end of bro
> Apart from the disks, you might also investigate using Opterons instead
> of Xeons. there appears to be some significant dent in performance
> between Opteron and Xeon. Xeons appear to spend more time in passing
> around ownership of memory cache lines in case of a spinlock.
> It's not yet clear
On Nov 9, 2007 10:40 AM, Claus Guttesen <[EMAIL PROTECTED]> wrote:
> > Apart from the disks, you might also investigate using Opterons instead
> > of Xeons. there appears to be some significant dent in performance
> > between Opteron and Xeon. Xeons appear to spend more time in passing
> > around o
Does the amount of memory allocate to work_mem get subtracted from
shared_buffers?
Example:
If work_mem is 1M and there are 10 connections and shared_buffers is
100M then would the total be 90 M left for shared_buffers?
Or does the amount of memory allocated for work_mem have nothing to
Campbell, Lance wrote:
Does the amount of memory allocate to work_mem get subtracted from
shared_buffers?
Example:
If work_mem is 1M and there are 10 connections and shared_buffers is
100M then would the total be 90 M left for shared_buffers?
Or does the amount of memory allocated for work_mem
On Fri, 9 Nov 2007 11:11:18 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote:
>
> > If the queries are complex, this is understable.
>
> The queries used for this comparison are trivial. There's only one table
> involved and there are no join
On Fri, 9 Nov 2007, Scott Marlowe wrote:
Not atm. Until new benchmarks are published comparing AMD's new
quad-core with Intel's ditto, Intel has the edge.
http://tweakers.net/reviews/657/6
For 8 cores, it appears AMD has the lead, read this (stolen from
another thread):
http://people.freebsd.o
How do you know when you should up the value of work_mem? Just play
with the number. Is there a query I could do that would tell me if
PostgreSql is performing SQL that could use more memory for sorting?
Thanks,
Lance Campbell
Project Manager/Software Architect
Web Services at Public Affairs
Un
Wow. That is a nice logging feature in 8.3!
Thanks,
Lance Campbell
Project Manager/Software Architect
Web Services at Public Affairs
University of Illinois
217.333.0382
http://webservices.uiuc.edu
-Original Message-
From: Bill Moran [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09,
On Nov 8, 2007, at 3:56 PM, Alan Hodgson wrote:
You can't touch RAID 10 for performance or reliability. The only
reason to
use RAID 5 or RAID 6 is to get more capacity out of the same drives.
Maybe you can't, but I can. I guess I have better toys than you :-)
---(
On Fri, 9 Nov 2007 12:08:57 -0600
"Campbell, Lance" <[EMAIL PROTECTED]> wrote:
> How do you know when you should up the value of work_mem? Just play
> with the number. Is there a query I could do that would tell me if
> PostgreSql is performing SQL that could use more memory for sorting?
8.2 an
On Nov 9, 2007 12:08 PM, Campbell, Lance <[EMAIL PROTECTED]> wrote:
> How do you know when you should up the value of work_mem? Just play
> with the number. Is there a query I could do that would tell me if
> PostgreSql is performing SQL that could use more memory for sorting?
Trial and error.
It is amazing, how after working with databases very actively for over 8
years, I am still learning things.
Thanks,
Lance Campbell
Project Manager/Software Architect
Web Services at Public Affairs
University of Illinois
217.333.0382
http://webservices.uiuc.edu
-Original Message-
From: S
On Nov 9, 2007 1:19 PM, Campbell, Lance <[EMAIL PROTECTED]> wrote:
> It is amazing, how after working with databases very actively for over 8
> years, I am still learning things.
The fun thing about postgresql is that just when you've got it figured
out, somebody will come along and improve it in
Bill Moran wrote:
> On Fri, 9 Nov 2007 11:11:18 -0500 (EST)
> Greg Smith <[EMAIL PROTECTED]> wrote:
>> On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote:
>>> If the queries are complex, this is understable.
>> The queries used for this comparison are trivial. There's only one table
>> involved and
On Nov 9, 2007, at 1:24 PM, Scott Marlowe wrote:
On Nov 9, 2007 1:19 PM, Campbell, Lance <[EMAIL PROTECTED]> wrote:
It is amazing, how after working with databases very actively for
over 8
years, I am still learning things.
The fun thing about postgresql is that just when you've got it figu
Tom,
Just to confirm you that your last commit fixed the problem:
lbo=# explain analyze select * from cms_items where ancestors LIKE '1062/%';
QUERY PLAN
-
On Nov 9, 2007 2:38 PM, Erik Jones <[EMAIL PROTECTED]> wrote:
>
> >
> > I imagine in a few years, hardly anyone using postgresql will remember
> > the ancient art of having either apostrophes in a row inside your
> > plpgsql functions...
>
> Speaking of that devil, I started working with Postgres m
We've had our PostgreSQL 8.1.4 installation configured to autovacuum
since January, but I suspect it might not be doing anything. Perhaps I
can determine what happens through the log files? Is there a summary of
which "when to log" settings in postgresql.conf should be set to get at
least table-l
David Crane wrote:
> We've had our PostgreSQL 8.1.4 installation configured to autovacuum
> since January, but I suspect it might not be doing anything. Perhaps I
> can determine what happens through the log files? Is there a summary of
> which "when to log" settings in postgresql.conf should be
Pepe Barbe wrote:
Hello,
I am having an issue on PostgreSQL 8.0.12. In the past we had
performance issues with the query planner for queries on some tables
where we knew we had indexes and it was doing a sequential scan, and for
this reason we issue "SET enable_seqscan = FALSE" for some queri
31 matches
Mail list logo
