Re: [PERFORM] PostgreSQL NetApp and NFS

2008-03-21 Thread Dawid Kuroczko
On Thu, Mar 20, 2008 at 8:32 PM, Chris Hoover [EMAIL PROTECTED] wrote: I just found out that my company is planning on migrating my databases from our current ISCSI storage solution to NetApps connected via NFS. I knew about the NetApp migration, but always assumed (and shame on me) that I

[PERFORM] Is AIX Concurrent IO safe with PostgreSQL?

2007-06-25 Thread Dawid Kuroczko
Hello, I am wondering if it is safe to assume that specifying cio mount option is safe with PostgreSQL. As far as I understand the CIO (AIX Concurrent I/O) means that filesystem does not serialize access to file blocks. In other words multiple threads can simultaneously read and write the file

Re: [PERFORM] Regarding Bitmap Scan

2006-10-17 Thread Dawid Kuroczko
On 10/17/06, soni de [EMAIL PROTECTED] wrote: I didn't understand theBitmap Scan andthe sentence indexes will be dynamically converted to bitmaps in memory. What does mean by Bitmap Scan in database? Can anybody help us regarding above query? Assume you have a table: CREATE TABLE foo (

Re: [PERFORM] Optimizing a huge_table/tiny_table join

2006-05-25 Thread Dawid Kuroczko
On 5/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Well, they're not my statistics; they're explain's. You mean there's a bug in explain? I agree that it makes no sense that the costs don't differ as much as one would expect, but you can see right there the numbers of rows for the two

Re: [HACKERS] [PERFORM] Big IN() clauses etc : feature proposal

2006-05-09 Thread Dawid Kuroczko
On 5/9/06, PFC [EMAIL PROTECTED] wrote: You might consider just selecting your primary key or a set of primary keys to involved relations in your search query. If you currently use select * this can make your result set very large. Copying all the result set to the temp. costs you

Re: [PERFORM] What's the best hardver for PostgreSQL 8.1?

2005-12-26 Thread Dawid Kuroczko
On 12/26/05, David Lang [EMAIL PROTECTED] wrote: raid5 writes n+1 blocks not n+n/2 (unless n=2 for a 3-disk raid). you can have a 15+1 disk raid5 array for example however raid1 (and raid10) have to write 2*n blocks to disk. so if you are talking about pure I/O needed raid5 wins hands down.

Re: [PERFORM] [IMPORTANT] - My application performance

2005-07-27 Thread Dawid Kuroczko
On 7/26/05, Roberto Germano Vieweg Neto [EMAIL PROTECTED] wrote: My application is using Firebird 1.5.2 My question is: Postgre SQL will be more faster than Firebird? How much (in percent)? I need about 20% to 50% more performance at my application. Can I get this migratin to postgresql

[PERFORM] Planner doesn't look at LIMIT?

2005-07-22 Thread Dawid Kuroczko
Hello, I have PostgreSQL 8.0.3 running on a workstation with 768 MB of RAM, under FreeBSD. And I have a 47-milion row table: qnex=# explain select * from log; QUERY PLAN

Re: [PERFORM] Planner doesn't look at LIMIT?

2005-07-22 Thread Dawid Kuroczko
On 7/22/05, Tom Lane [EMAIL PROTECTED] wrote: Dawid Kuroczko [EMAIL PROTECTED] writes: qnex=# EXPLAIN SELECT * FROM log NATURAL JOIN useragents LIMIT 1; Limit (cost=15912.20..15912.31 rows=1 width=272) - Hash Join (cost=15912.20..5328368.96 rows=47044336 width=272) This is quite

Re: [PERFORM] Planner doesn't look at LIMIT?

2005-07-22 Thread Dawid Kuroczko
On 7/22/05, Tom Lane [EMAIL PROTECTED] wrote: This is quite strange. The nestloop plan definitely should be preferred in the context of the LIMIT, considering that it has far lower estimated cost. And it is preferred in simple tests for me. After a suitable period of contemplating my

Re: [PERFORM] Looking for tips

2005-07-19 Thread Dawid Kuroczko
On 7/19/05, Oliver Crosby [EMAIL PROTECTED] wrote: We had low resource utilization and poor throughput on inserts of thousands of rows within a single database transaction. There were a lot of configuration parameters we changed, but the one which helped the most was wal_buffers -- we

Re: [PERFORM] slow joining very large table to smaller ones

2005-07-18 Thread Dawid Kuroczko
On 7/15/05, Bruno Wolff III [EMAIL PROTECTED] wrote: On Thu, Jul 14, 2005 at 16:29:58 -0600, Dan Harris [EMAIL PROTECTED] wrote: Ok, I tried this one. My ssh keeps getting cut off by a router somewhere between me and the server due to inactivity timeouts, so all I know is that both

Re: [PERFORM] JFS fastest filesystem for PostgreSQL?

2005-07-14 Thread Dawid Kuroczko
On 7/14/05, Jeffrey W. Baker [EMAIL PROTECTED] wrote: [reposted due to delivery error -jwb] I just took delivery of a new system, and used the opportunity to benchmark postgresql 8.0 performance on various filesystems. The system in question runs Linux 2.6.12, has one CPU and 1GB of system

Re: [PERFORM] Surprizing performances for Postgres on Centrino

2005-07-07 Thread Dawid Kuroczko
On 7/7/05, Jean-Max Reymond [EMAIL PROTECTED] wrote: On my laptop whith Centrino 1.6 GHz, 512 Mb RAM, - it is solved in 1h50' for Linux 2.6 - it is solved in 1h37' for WXP Professionnal (troll on WXP better tan Linux ;-) troll off) [...] I test CPU, memory performance on my laptop and it

Re: [PERFORM] tricky query

2005-06-29 Thread Dawid Kuroczko
On 6/28/05, John A Meinel [EMAIL PROTECTED] wrote: Actually, if you already have a lower bound, then you can change it to: SELECT t1.id+1 as id_new FROM id_test t1 WHERE t1.id id_min AND NOT EXISTS (SELECT t2.id FROM id_test t2 WHERE t2.id = t1.id+1) ORDER BY

Re: [PERFORM] SURVEY: who is running postgresql on 8 or more CPUs?

2005-06-02 Thread Dawid Kuroczko
On 6/2/05, Dirk Lutzebäck [EMAIL PROTECTED] wrote: I just got one reply for this survey. Is almost nobody using postgresql on 8+ machines? My guess is when someone is using PostgreSQL on 8+ machine, she's in highly competitive (or sensitive) market and either cannot give company's work details

Re: [PERFORM] slow queries, possibly disk io

2005-05-26 Thread Dawid Kuroczko
On 5/26/05, Josh Close [EMAIL PROTECTED] wrote: I have some queries that have significan't slowed down in the last couple days. It's gone from 10 seconds to over 2 mins. The cpu has never gone over 35% in the servers lifetime, but the load average is over 8.0 right now. I'm assuming this is

Re: [PERFORM] immutable functions vs. join for lookups ?

2005-04-22 Thread Dawid Kuroczko
On 4/21/05, Enrico Weigelt [EMAIL PROTECTED] wrote: * Tom Lane [EMAIL PROTECTED] wrote: snip Yeah, I was actually thinking about a two-step process: inline the function to produce somethig equivalent to a handwritten scalar sub-SELECT, and then try to convert sub-SELECTs into joins.

Re: [PERFORM] immutable functions vs. join for lookups ?

2005-04-22 Thread Dawid Kuroczko
On 4/21/05, Enrico Weigelt [EMAIL PROTECTED] wrote: snip Even if your data never changes it *can* change so the function should be at most stable not immutable. okay, the planner sees that the table could potentionally change. but - as the dba - I'd like to tell him, this table *never*

Re: [PERFORM] immutable functions vs. join for lookups ?

2005-04-20 Thread Dawid Kuroczko
On 4/20/05, Jim C. Nasby [EMAIL PROTECTED] wrote: You should re-run the function test using SQL as the function language instead of plpgsql. There might be some performance to be had there. Yay! You're right! I wonder why have I forgotten about LANGUAGE SQL. :) It's 30 seconds vs 5 seconds

Re: [PERFORM] How to improve db performance with $7K?

2005-04-20 Thread Dawid Kuroczko
On 4/19/05, Mohan, Ross [EMAIL PROTECTED] wrote: Clustered file systems is the first/best example that comes to mind. Host A and Host B can both request from diskfarm, eg. Something like a Global File System? http://www.redhat.com/software/rha/gfs/ (I believe some other company did develop it

Re: [PERFORM] immutable functions vs. join for lookups ?

2005-04-18 Thread Dawid Kuroczko
On 4/15/05, Enrico Weigelt [EMAIL PROTECTED] wrote: a) SELECT items.a, items.b, ..., users.username FROM items, users WHERE items.uid = users.uid; c) CREATE FUNCTION id2username(oid) RETURNS text LANGUAGE 'SQL' IMMUTABLE AS ' SELECT username AS RESULT FROM users WHERE

Re: [PERFORM] immutable functions vs. join for lookups ?

2005-04-18 Thread Dawid Kuroczko
On 4/18/05, Merlin Moncure [EMAIL PROTECTED] wrote: d) self-join with a function ;) EXPLAIN ANALYZE SELECT * FROM (SELECT n, id2username(n) AS username FROM (SELECT DISTINCT n FROM aaa) AS values) AS v_lookup RIGHT JOIN aaa USING (n); That's pretty clever. It sure seems like the

Re: [PERFORM] speed of querry?

2005-04-14 Thread Dawid Kuroczko
On 4/14/05, Joel Fradkin [EMAIL PROTECTED] wrote: I have done a vacuum and a vacuum analyze. I can try again for kicks, but it is not in production so no new records are added and vacuum analyze is ran after any mods to the indexes. I am still pursuing Dell on why the monster box is so much

Re: [PERFORM] speed of querry?

2005-04-14 Thread Dawid Kuroczko
On 4/14/05, Joel Fradkin [EMAIL PROTECTED] wrote: Josh from commandprompt.com had me alter the config to have default_statistics_target = 250 Is this somehow related to what your asking me to do? I did do an analyze, but have only ran the viw a few times. well, he did suggest the right

Re: [PERFORM] best practices with index on varchar column

2005-03-23 Thread Dawid Kuroczko
On Wed, 23 Mar 2005 12:11:56 +0800, Michael Ryan S. Puncia [EMAIL PROTECTED] wrote: I have an experience using LIKE in a VARCHAR column and select statement suffers a lot so I decided to go back in CHAR Note: my database has about 50 millions records a b tree index Strange... According to

Re: [PERFORM] best practices with index on varchar column

2005-03-22 Thread Dawid Kuroczko
On Tue, 22 Mar 2005 18:22:24 +0900, Layet Benjamin [EMAIL PROTECTED] wrote: Can I use an index on a varchar column to optimize the SELECT queries that use column LIKE 'header%' ? If yes what is the best tree algotithm to use ? Yes, that is the correct place. The best tree algorithm is

Re: [PERFORM] What about utility to calculate planner cost constants?

2005-03-22 Thread Dawid Kuroczko
On Mon, 21 Mar 2005 14:59:56 -0800, Josh Berkus josh@agliodbs.com wrote: If by not practical you mean, no one has implemented a multivariable testing approach, I'll agree with you. But multivariable testing is definitely a valid statistical approach to solving just such problems. Well, not

Re: [PERFORM] Flattening a kind of 'dynamic' table

2005-01-28 Thread Dawid Kuroczko
On Thu, 27 Jan 2005 12:43:56 -0500, Alexandre Leclerc [EMAIL PROTECTED] wrote: On Thu, 27 Jan 2005 17:27:40 +0100, Dawid Kuroczko [EMAIL PROTECTED] wrote: On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc [EMAIL PROTECTED] wrote: Here a normal listing of design.product_department_time

Re: [PERFORM] Flattening a kind of 'dynamic' table

2005-01-28 Thread Dawid Kuroczko
On Fri, 28 Jan 2005 10:24:37 -0800, Joe Conway [EMAIL PROTECTED] wrote: Alexandre Leclerc wrote: I'm a little bit confused on how to install this contirb. I know my contrib package is installed, but I don't know how to make it work in postgresql. (Using 7.4.5-1mdk on Mandrake Linux.)

Re: [PERFORM] Flattening a kind of 'dynamic' table

2005-01-27 Thread Dawid Kuroczko
On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc [EMAIL PROTECTED] wrote: Here a normal listing of design.product_department_time: product_id | department_id | req_time +---+-- 906 | A | 3000 906 | C | 3000

[PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Dawid Kuroczko
On Sat, 22 Jan 2005 12:13:00 +0900 (JST), Tatsuo Ishii [EMAIL PROTECTED] wrote: IMO the bottle neck is not WAL but table/index bloat. Lots of updates on large tables will produce lots of dead tuples. Problem is, There' is no effective way to reuse these dead tuples since VACUUM on huge tables

Re: [PERFORM] Low Performance for big hospital server ..

2005-01-06 Thread Dawid Kuroczko
On Wed, 5 Jan 2005 22:35:42 +0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Now I turn hyperthreading off and readjust the conf . I found the bulb query that was : update one flag of the table [8 million records which I think not too much] Ahh, the huge update. Below are my hints I've

[PERFORM] When to bump up statistics?

2004-11-19 Thread Dawid Kuroczko
ALTER TABLE foo ALTER COLUMN bar SET STATISTICS n; . I wonder what are the implications of using this statement, I know by using, say n=100, ANALYZE will take more time, pg_statistics will be bigger, planner will take longer time, on the other hand it will make better decisions... Etc, etc.

[PERFORM] ext3 journalling type

2004-11-08 Thread Dawid Kuroczko
The ext3fs allows to selet type of journalling to be used with filesystem. Journalling pretty much mirrors the work of WAL logging by PostgreSQL... I wonder which type of journalling is best for PgSQL in terms of performance. Choices include: journal All data

[PERFORM] Views, joins and LIMIT

2004-10-11 Thread Dawid Kuroczko
I've been wondering... Suppose we have two tables CREATE TABLE messages ( message_id serial PRIMARY KEY, message text NOT NULL ); CREATE TABLE entries ( entry_id serial PRIMARY KEY, message_id integer NOT NULL REFERENCES messages ); And we have a join: SELECT entry_id,message FROM

[PERFORM] integer[] indexing.

2004-10-08 Thread Dawid Kuroczko
I have a large table with a column: ids integer[] not null most of these entries (over 95%) contain only one array element, some can contain up to 10 array elements. seqscan is naturally slow. GIST on int_array works nice, but GIST isn't exactly a speed daemon when it comes to updating. So I