Re: [PERFORM] SSD + RAID

Am 13.11.2009 um 14:57 schrieb Laszlo Nagy: I was thinking about ARECA 1320 with 2GB memory + BBU. Unfortunately, I cannot find information about using ARECA cards with SSD drives. They told me: currently not supported, but they have positive customer reports. No date yet for implementatio

Re: [PERFORM] Best suiting OS

Am 05.10.2009 um 23:44 schrieb Karl Denninger: Axel Rau wrote: Am 05.10.2009 um 20:06 schrieb Karl Denninger: gjournal, no. ZFS has potential stability issues - I am VERY interested in it when those are resolved. It looks good on a test platform but I'm unwilling to run

Re: [PERFORM] Best suiting OS

Am 05.10.2009 um 20:06 schrieb Karl Denninger: gjournal, no. ZFS has potential stability issues - I am VERY interested in it when those are resolved. It looks good on a test platform but I'm unwilling to run it in production; there are both reports of crashes and I have been able to cra

Re: [PERFORM] Best suiting OS

Am 05.10.2009 um 19:42 schrieb Karl Denninger: I have not yet benchmarked FreeBSD 8.x - my production systems are all on FreeBSD 7.x at present. The improvement going there from 6.x was MASSIVE. 8.x is on my plate to start playing with in the next couple of months. Did you ever try gjou

Re: [PERFORM] UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)

Am 24.09.2008 um 12:18 schrieb Laszlo Nagy: Should I use gjournal on FreeBSD 7? Or just soft updates? I'm using gjournal for 5 weeks now on my production server. There are 4 journaled filesystems on a raid controller with BBU. pg uses 23GB out of 1.6TB. I can't see any performance impact or

Re: [PERFORM] performance impact of non-C locale

Am 11.09.2008 um 11:29 schrieb Peter Eisentraut: What other performance impacts can be expected? The performance impact is mainly with string comparisons and sorts. I suggest you run your own tests to find out what is acceptable in your scenario. Im not yet convinced to switch to non-C

[PERFORM] performance impact of non-C locale

Hi everyone, some erp software requires a change of my pgsql cluster from locale Cencoding UTF-8 to locale de_DE.UTF-8 encoding UTF-8 Most of my databases have only ASCII text data (8 bit UTF8 code range) in the text columns. Does the above change influenc

Re: [PERFORM] Delete Cascade FK speed issue

Am 03.07.2007 um 13:33 schrieb Michael Fuhr: Something like the following should work for single-column foreign keys: Nice query. Found immediately 2 missing indexes. (-;) Axel - Axel Rau, ☀Frankfurt , Germany

Re: [PERFORM] configuring new server / many slow disks?

Am 09.03.2007 um 12:42 schrieb Richard Huxton: Axel Rau wrote: Hi performers, after following this list for a while, I try to configure a database server with a limited budget. Planned are 2 databases - archiveopteryx - http://www.archiveopteryx.org/sql-schema.html - ERDB - https

Re: [PERFORM] configuring new server / many slow disks?

Am 08.03.2007 um 12:30 schrieb Axel Rau: Can I expect similar performance as 5 drives at 10k rpm (same costs)? Should I revert to a single-CPU to prevent from oscillating cache updates between CPUS? Anybody experience about NUMA stuff with FreeBSD? Do you have any suggestions to enhance

[PERFORM] configuring new server / many slow disks?

suggestions to enhance the configuration, staying at cost level? Please advice. Axel - Axel Rau, ☀Frankfurt , Germany +49 69 9514 18 0 ---(end of broadcast

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

n it be used to distinguish a file from a directory? Yes, the S_IFDIR bit identifies directories, but the whole lstat column is base64 encoded Similarly for the md5 column--what would it contain for a directory? It seems to contain 0. Axel Axel Rau, ☀Frankfurt , Germany

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

dir_depth(path) and in the query do a check for directories with a given prefix and the expected dir_depth. Still I must check for flatfiles in those subdirectories... See my clarification here http://archives.postgresql.org/pgsql-performance/2006-07/msg00311.php Axel Axel Rau, ☀

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

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

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

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

f a subdirectory. Perhaps in a temporary table? Assuming you can't make changes to the schema, what about the query? Can be changed. You've got this: Please reconsider your proposals with the above It's hard to say without knowing what's actual

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

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 ~ &

[PERFORM] directory tree query with big planner variation

ilenameid = fn.filenameid) Filter: (name <> ''::text) -> Bitmap Index Scan on filename_pkey (cost=0.00..2.00 rows=1 width=0) (actual time=0.087..0.087 rows=1 loops=1050)