Re: [PERFORM] serious problems with vacuuming databases

2006-04-24 Thread Tomas Vondra
> Hi Tomas, > > Tomas wrote: > We've decided to remove unneeded 'old' data, which means removing about > 99.999% of rows from tables A, C and D (about 2 GB of data). At the > beginning, the B table (containing aggregated from A, C and D) was emptied > (dropped and created) and filled in with curre

[PERFORM] Easy question

2006-04-24 Thread clemens . bertschler
Hi List I have maybe an easy question but i do not find an answer, i have this SQL query: SELECT geom,group,production_facs FROM south_america WHERE municipio = '' OR municipio = 'ACRE' OR municipio = 'ADJUNTAS'

[PERFORM] Worsening performance with 7.4 on flash-based system

2006-04-24 Thread Greg Stumph
We are experiencing gradually worsening performance in PostgreSQL 7.4.7, on a system with the following specs: Linux OS (Fedora Core 1, 2.4 kernal) Flash file system (2 Gig, about 80% full) 256 Meg RAM 566 MHz Celeron CPU We use Orbit 2.9.8 to access PostGres. The database contains 62 tables. Wh

[PERFORM] security for row level but not based on Database user's login

2006-04-24 Thread Friends
Hi I need to set security for row level but not based on Database user's login. It should be based on the user table login. For the particular user I need to allow only the particular records to access insert, update delete and select. Let me explain clearly For example think we are using asp/as

[PERFORM] Introducing a new linux readahead framework

2006-04-24 Thread Wu Fengguang
Greetings, I'd like to introduce a new readahead framework of the linux kernel: http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1021.html HOW IT WORKS In adaptive readahead, the context based method may be of particular interest to postgresql users. It works by peeking into the file cache a

[PERFORM] Slow deletes in 8.1 when FKs are involved

2006-04-24 Thread Will Reese
I'm preparing for an upgrade from PostgreSQL 7.4.5 to 8.1.3, and I noticed a potential performance issue. I have two servers, a dual proc Dell with raid 5 running PostgreSQL 7.4, and a quad proc Dell with a storage array running PostgreSQL 8.1. Both servers have identical postgresql.conf se

Re: [PERFORM] Hardware: HP StorageWorks MSA 1500

2006-04-24 Thread Mark Kirkwood
Mikael Carneholm wrote: There are two SCSI U320 buses, with seven bays on each. I don't know what the overhead of SCSI is, but you're obviously not going to get > 490MB/s for each set of seven even if the FC could do it. You should be able to get close to 300Mb/s on each SCSI bus - provide

Re: [PERFORM] ip address data type

2006-04-24 Thread Steve Atkins
On Apr 24, 2006, at 3:45 PM, Sriram Dandapani wrote: Hi I have queries that use like operators and regex patterns to determine if an ip address is internal or external (this is against a table with say 100 million distinct ip addresses). Does the inet data type offer comparison/searc

Re: [PERFORM] ip address data type

2006-04-24 Thread Jim C. Nasby
On Mon, Apr 24, 2006 at 03:45:14PM -0700, Sriram Dandapani wrote: > Hi > > I have queries that use like operators and regex patterns to determine > if an ip address is internal or external (this is against a table with > say 100 million distinct ip addresses). > > Does the inet data type offer co

[PERFORM] ip address data type

2006-04-24 Thread Sriram Dandapani
Hi   I have queries that use like operators and regex patterns to determine if an ip address is internal or external (this is against a table with say 100 million distinct ip addresses).   Does the inet data type offer comparison/search performance benefits over plain text for ip addres

Re: [PERFORM] Index on function less well cached than "regular" index ?

2006-04-24 Thread Tom Lane
"Paul Mackay" <[EMAIL PROTECTED]> writes: > ... > EXPLAIN shows that an index scan is used by the planner. A query returning > the maximum 200 number of records takes around 20 ms. What is surprising is > that the same query executed several times takes practically the same time, > as if the result

Re: [PERFORM] GROUP BY Vs. Sub SELECT

2006-04-24 Thread Jim C. Nasby
On Mon, Apr 24, 2006 at 12:07:39PM -0700, Richard Broersma Jr wrote: > > > I'd like to get more info on EXPLAIN ANALYZE output... where can I read more > > about it? > > I believe this link has what you are looking for: > http://www.postgresql.org/docs/8.1/interactive/performance-tips.html http:

Re: [PERFORM] Hardware: HP StorageWorks MSA 1500

2006-04-24 Thread Mikael Carneholm
> If I'm reading the original post correctly, the biggest issue is > likely to be that the 14 disks on each 2Gbit fibre channel will be > throttled to 200Mb/s by the channel , when in fact you could expect > (in RAID 10 > arrangement) to get about 7 * 70 Mb/s = 490 Mb/s. > The two controllers a

Re: [PERFORM] GROUP BY Vs. Sub SELECT

2006-04-24 Thread Richard Broersma Jr
> I'd like to get more info on EXPLAIN ANALYZE output... where can I read more > about it? I believe this link has what you are looking for: http://www.postgresql.org/docs/8.1/interactive/performance-tips.html Regards, Richard Broersma Jr. ---(end of broadcast)

Re: [PERFORM] Hardware: HP StorageWorks MSA 1500

2006-04-24 Thread Alex Hayward
On Mon, 24 Apr 2006, Mark Kirkwood wrote: > If I'm reading the original post correctly, the biggest issue is likely > to be that the 14 disks on each 2Gbit fibre channel will be throttled to > 200Mb/s by the channel , when in fact you could expect (in RAID 10 > arrangement) to get about 7 * 70 Mb/

Re: [PERFORM] GROUP BY Vs. Sub SELECT

2006-04-24 Thread Bruno Almeida do Lago
OK! I totally understand what you said. I'll load this table with a simulated data and see how PG deals with it. About the queries being different, yes, I'm sure they are :-) I did not mention that application is able to handle both. I'd like to get more info on EXPLAIN ANALYZE output... where c

[PERFORM] Index on function less well cached than "regular" index ?

2006-04-24 Thread Paul Mackay
I have a table of ~ 41 000 rows with an index on the result of a function applied to a certain text column (the function basically removes "neutral" or common words like "the","on","a", etc. from the string). I then execute a query with a where clause on this function result with an order by on the

Re: [PERFORM] Slow deletes in 8.1 when FKs are involved

2006-04-24 Thread Jim C. Nasby
On Sun, Apr 23, 2006 at 09:41:14PM -0500, Will Reese wrote: > I'm preparing for an upgrade from PostgreSQL 7.4.5 to 8.1.3, and I > noticed a potential performance issue. > > I have two servers, a dual proc Dell with raid 5 running PostgreSQL > 7.4, and a quad proc Dell with a storage array run

Re: [PERFORM] Recovery will take 10 hours

2006-04-24 Thread Simon Riggs
On Sun, 2006-04-23 at 22:46 -0600, Brendan Duddridge wrote: > So how do you overlap the restore process with the retrieving of files? The restore command can be *anything*. You just write a script... > Our restore command is: > > restore_command = 'gunzip %p' > > If I change it to: > > restor

Re: [PERFORM] Recovery will take 10 hours

2006-04-24 Thread Markus Schaber
Hi, Brandan, Brendan Duddridge wrote: > So how do you overlap the restore process with the retrieving of files? You need a shell script as restore command that does both uncompressing the current file, and starting a background decompress of the next file(s). It also has to check whether the cur