Re: [PERFORM] PostgreSQL scalability on Sun UltraSparc T1

2006-07-31 Thread Jignesh Shah
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

Re: [PERFORM] PostgreSQL scalability on Sun UltraSparc T1

2006-07-31 Thread Arjen van der Meijden
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 11

Re: [PERFORM] sub select performance due to seq scans

2006-07-31 Thread Richard Huxton
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

Re: [PERFORM] How to increase performance?

2006-07-31 Thread Richard Huxton
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

Re: [PERFORM] Query 200x slower on server [PART 2]

2006-07-31 Thread Richard Huxton
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

[PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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:

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread 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 ~ '^%@/[^/]*/$' The schema could be a lot more intelligent here. (E.g., store

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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

[PERFORM] Partitioning / constrain exlusion not working with %-operator

2006-07-31 Thread Martin Lesser
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

Re: [PERFORM] sub select performance due to seq scans

2006-07-31 Thread Rod Taylor
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

Re: [PERFORM] Partitioning / constrain exlusion not working with %-operator

2006-07-31 Thread Tom Lane
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 limited

Re: [PERFORM] sub select performance due to seq scans

2006-07-31 Thread H Hale
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

Re: [PERFORM] sub select performance due to seq scans

2006-07-31 Thread Tom Lane
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 flatomfilesysentry_pkey

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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 +-

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread 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? Mike Stone ---(end of broadcast)--- TIP 1: if posting/reading through

Re: [PERFORM] Performances with new Intel Core* processors

2006-07-31 Thread Merlin Moncure
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.

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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

Re: [PERFORM] PostgreSQL scalability on Sun UltraSparc T1

2006-07-31 Thread Merlin Moncure
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 MySQL

Re: [PERFORM] sub select performance due to seq scans

2006-07-31 Thread H Hale
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: H Hale

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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

Re: [PERFORM] Performances with new Intel Core* processors

2006-07-31 Thread Arjen van der Meijden
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

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Michael Stone
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

Re: [PERFORM] directory tree query with big planner variation

2006-07-31 Thread Axel Rau
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

Re: [PERFORM] Performances with new Intel Core* processors

2006-07-31 Thread Bruce Momjian
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:

Re: [PERFORM] Performances with new Intel Core* processors

2006-07-31 Thread Scott Marlowe
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 mainly

Re: [PERFORM] Performances with new Intel Core* processors

2006-07-31 Thread Vivek Khera
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.

[PERFORM] Are there any performance penalty for opposite edian platform combinations....

2006-07-31 Thread Guoping Zhang
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