Vivek,
On 7/31/06 2:04 PM, "Vivek Khera" <[EMAIL PROTECTED]> wrote:
> No, but it *does* matter how fast said processor can sling the memory
> around, and in my experience, the opterons have been much better at
> that due to the efficiency of the memory transport layer.
My Mac laptop with a Core
Hello,
I apologize that if the similar questions were already asked and answered
before.
Here is a go:
a) If we have application clients running on a Solaris 10/SPARC box and
database server running on a Solaris10 X_86 box; further, we have a few
tables, in which we split an integer type of f
On Jul 31, 2006, at 12:30 PM, Arjen van der Meijden wrote:
For a database system, however, processors hardly ever are the main
bottleneck, are they? So you should probably go for a set of "fast
processors" from your favorite supplier and focus mainly on lots of
memory and fast disks. Wheth
On Mon, 2006-07-31 at 11:30, Arjen van der Meijden wrote:
> On 31-7-2006 17:52, Merlin Moncure wrote:
> For a database system, however, processors hardly ever are the main
> bottleneck, are they? So you should probably go for a set of "fast
> processors" from your favorite supplier and focus mai
Good to know. We have been waiting for performance comparisons on
the new Intel CPUs.
---
Arjen van der Meijden wrote:
> On 31-7-2006 17:52, Merlin Moncure wrote:
> > On 7/31/06, Jonathan Ballet <[EMAIL PROTECTED]> wrote:
>
Am 31.07.2006 um 19:08 schrieb Michael Stone:
I never saw a column description--that would certainly help. :) I
saw a schema, but not an explanation of what the elements do. From
what I can understand of what you're saying, it is sounding as
though the bacula.file table contains an entry f
On Mon, Jul 31, 2006 at 05:54:41PM +0200, Axel Rau wrote:
The file table is the biggest one, because it contains one row per
backup job and file (see my column description).
I never saw a column description--that would certainly help. :) I saw a
schema, but not an explanation of what the elem
On 31-7-2006 17:52, Merlin Moncure wrote:
On 7/31/06, Jonathan Ballet <[EMAIL PROTECTED]> wrote:
Hello,
I've read a lot of mails here saying how good is the Opteron with
PostgreSQL,
and a lot of people seems to recommend it (instead of Xeon).
I am a huge fan of the opteron but intel certain
Am 31.07.2006 um 15:53 schrieb Mark Lewis:
It seems like you might be able to avoid the expensive directory
lookups
entirely without changing the schema by defining an immutable function
dir_depth(path), which would just count the number of forward slashes.
Then create a functional index on d
Am 31.07.2006 um 17:54 schrieb Axel Rau:
Tweaking your query and omitting the RTRIM/REPLACE stuff, I get:
My example did not cover the case of empty subdirectories, in which
case your simplified query fails:
---
path | children
---
Tom, It is unique. Indexes: "flatomfilesysentry_pkey" PRIMARY KEY, btree (objectid) "capsa_flatomfilesysentry_name_idx" btree (name) Foreign-key constraints: "objectid" FOREIGN KEY (objectid) REFERENCES capsa_sys.master(objectid) ON DELETE CASCADE Tom Lane <[EMAIL PROTECTED]> wrote:
On 7/29/06, Jochem van Dieten <[EMAIL PROTECTED]> wrote:
Tweakers.net has done a database performance test between a Sun T2000 (8
core T1) and a Sun X4200 (2 dual core Opteron 280). The database
benchmark is developed inhouse and represents the average query pattern
from their website. It is MySQ
Am 31.07.2006 um 17:21 schrieb Michael Stone:
On Mon, Jul 31, 2006 at 05:06:00PM +0200, Axel Rau wrote:
Please reconsider your proposals with the above
I'm not sure what you're getting at; could you be more specific?
Let's see...
Am 31.07.2006 um 15:30 schrieb Michael Stone:
And then what
On 7/31/06, Jonathan Ballet <[EMAIL PROTECTED]> wrote:
Hello,
I've read a lot of mails here saying how good is the Opteron with PostgreSQL,
and a lot of people seems to recommend it (instead of Xeon).
I am a huge fan of the opteron but intel certainly seems to have a
winner for workstations.
On Mon, Jul 31, 2006 at 05:06:00PM +0200, Axel Rau wrote:
Please reconsider your proposals with the above
I'm not sure what you're getting at; could you be more specific?
Mike Stone
---(end of broadcast)---
TIP 1: if posting/reading through Usen
Am 31.07.2006 um 15:30 schrieb Michael Stone:
If I understand the intend of this SQL,
Let me show the tables first:
Table "bacula.path"( 65031 rows)
Column | Type | Modifiers
+-
+-
H Hale <[EMAIL PROTECTED]> writes:
> -> Bitmap Heap Scan on flatomfilesysentry (cost=2.00..274.38 rows=3238
> width=30) (actual time=0.011..0.013 rows=1 loops=6473)
> Recheck Cond: (flatomfilesysentry.objectid = "outer".dstobj)
> -> Bitmap Index Scan on flatomfilesysentr
Look at that second seq-scan (on flatommemberrelation) - it's looping 5844 times (once for each row in flatmfilesysentry). I'd expect PG to materialise the seq-scan once and then join (unless I'm missing something, the subselect just involves the one test against a constant).I'm guessing something
It seems like you might be able to avoid the expensive directory lookups
entirely without changing the schema by defining an immutable function
dir_depth(path), which would just count the number of forward slashes.
Then create a functional index on dir_depth(path) and in the query do a
check for di
On Mon, Jul 31, 2006 at 01:54:24PM +0200, Axel Rau wrote:
Am 31.07.2006 um 13:15 schrieb Michael Stone:
On Mon, Jul 31, 2006 at 12:48:11PM +0200, Axel Rau wrote:
WHERE P.path ~ '^%@/[^/]*/$' ) AS NLPC
This can't be indexed. You might try something like WHERE P.path
LIKE '[EMAI
Rod Taylor <[EMAIL PROTECTED]> writes:
>> Nested Loop IN Join (cost=0.00..1386.45 rows=5809 width=14) (actual
>> time=2.933..101467.463 rows=5841 loops=1)
>> Join Filter: ("outer".objectid = "inner".dstobj)
>> -> Seq Scan on flatomfilesysentry (cost=0.00..368.09 rows=5809
>> width=30) (actual ti
Hello,
I've read a lot of mails here saying how good is the Opteron with PostgreSQL,
and a lot of people seems to recommend it (instead of Xeon).
However, it seems that new Intel processors, Core Duo and Core 2 Duo, performs
very well, in desktop environment at least.
I wonder what can we expec
Martin Lesser <[EMAIL PROTECTED]> writes:
> I try to partition a large table (~ 120 mio. rows) into 50 smaller
> tables but using the IMO immutable %-function constraint exclusion
> does not work as expected:
The constraint exclusion mechanism is not as bright as you think.
There are some very lim
> capsa=# explain analyze select name from capsa.flatomfilesysentry
> where objectid in ( select dstobj from capsa.flatommemberrelation
> where srcobj = 'c1c7304a-1fe1-11db-8af7-001143214409');
>
>
>QUERY PLAN
> -
I try to partition a large table (~ 120 mio. rows) into 50 smaller
tables but using the IMO immutable %-function constraint exclusion
does not work as expected:
CREATE TABLE tt_m (id1 int, cont varchar);
CREATE TABLE tt_0 (check (id1 % 50 = 0)) INHERITS (tt_m);
CREATE TABLE tt_1 (check (id1 % 50 =
Am 31.07.2006 um 13:15 schrieb Michael Stone:
On Mon, Jul 31, 2006 at 12:48:11PM +0200, Axel Rau wrote:
WHERE P.path ~ '^%@/[^/]*/$' ) AS NLPC
This can't be indexed. You might try something like WHERE P.path
LIKE '[EMAIL PROTECTED]' AND P.path ~ '^%@/[^/]*/$'
Why does it qui
On Mon, Jul 31, 2006 at 12:48:11PM +0200, Axel Rau wrote:
WHERE P.path ~ '^%@/[^/]*/$' ) AS NLPC
This can't be indexed. You might try something like
WHERE P.path LIKE '[EMAIL PROTECTED]' AND P.path ~ '^%@/[^/]*/$'
The schema could be a lot more intelligent here. (E.g., store pa
Hi group,
this is a directory tree query for a backup system (http://
sourceforge.net/projects/bacula).
You provide a path and get back the names of the children plus a
boolean telling if the child has itself children.
The "%@" stands for the initial path:
NbForYou wrote:
See Query 200x slower on server [PART 1] before reading any further
Cant' find it. Sorry.
QUERY PLAN ON MY HOME SERVER
[snip]
Total runtime: 125.432 ms
This means that the Query is 200 times slower on the webhost!
How can I resolve this?
First - what is different betwee
Hristo Markov wrote:
Hello,
My name is Hristo Markov. I am software developer.
I am developing software systems (with C/C++ program language) that work on Windows operation system and uses ODBC driver and ACCESS database. I want to change database with PostgreSQL.
The systems working w
H Hale wrote:
I am testing a query what that has a sub-select. The query performance is very very poor as shown below due to the use of sequencial scans. The actual row count of both tables is also shown. It appears the row count shown by explain analyze does not match the actual count. Columns d
Hi Jignesh,
It was a cvs-checkout of 8.2 devel, compiled using:
CPPFLAGS="-fast -xtarget=ultraT1 -xnolibmopt" CC=/opt/SUNWspro/bin/cc
./configure --without-readline
We'd gotten a specially adjusted Solaris version from Sun Holland for
the T2000. It was a dvd with a Solaris flar archive from 1
Hi Arjen,
I am curious about your Sun Studio compiler options also.
Can you send that too ?
Any other tweakings that you did on Solaris?
Thanks.
Regards,
Jignesh
Arjen van der Meijden wrote:
On 29-7-2006 19:01, Joshua D. Drake wrote:
Well I would be curious about the postgresql.conf and how
33 matches
Mail list logo
