Re: [PERFORM] avoiding seqscan?

2003-09-29 Thread Gaetano Mendola
to documentation about it, if so? Thanks, Palle Are not absolutelly bad but sometimes that path that you choose is not the optimal, in postgres 7.4 use the explicit join will be less limitative for the planner. Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] avoiding seqscan?

2003-09-29 Thread Gaetano Mendola
this form of join ? When and if is not necessary use the implicit form. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] avoiding seqscan?

2003-09-29 Thread Gaetano Mendola
to documentation about it, if so? Thanks, Palle Are not absolutelly bad but sometimes that path that you choose is not the optimal, in postgres 7.4 the think will be better. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched

Re: [PERFORM] IMMUTABLE function's flag do not work: 7.3.4, plpgsql

2003-10-09 Thread Gaetano Mendola
with all-constant arguments can be immediately replaced with the function value. The doc say can be not must and will be. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Compare rows

2003-10-09 Thread Gaetano Mendola
for the next revision and we're leaving ourselves open for a rewrite much to the boss's chagrin. I'm not sure about the save in storage. See the Hannu Krosing arguments. Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet

Re: [PERFORM] index file bloating still in 7.4 ?

2003-10-21 Thread Gaetano Mendola
, assuming you've turned on query echoing. Or is enough do a ps -eafwww | grep post to see the state of the connections Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Optimize

2003-11-24 Thread Gaetano Mendola
on it to see which one is the bottleneck. If you are running the 7.4 you can see on the log the total ammount for each query. Let us know. Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister

Re: [PERFORM] Optimize

2003-11-24 Thread Gaetano Mendola
Torsten Schulz wrote: Gaetano Mendola wrote: Torsten Schulz wrote: Yes, I know: very difficult question, but I don't know what to do now. Our Server: Dual-CPU with 1.2 GHz 1.5 GB RAM Our Problem: We are a Community. Between 19 and 21 o clock we have 350 User in the Community

Re: [PERFORM] [Fwd: Re: Optimize]

2003-11-25 Thread Gaetano Mendola
. with this query I see how much queries running, but the field current_query are free, so i can't see which queries are very slow. You must perform that query with permission of super_user. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9

Re: [PERFORM] Has anyone run on the new G5 yet

2003-12-03 Thread Gaetano Mendola
with bigmem turned on. This box is used only for the warehouse. All the ETL work is done on this machine as well. DB version is postgreSQL 7.4. Are you experiencing improvment using the hyper-threading ? Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] autovacuum daemon stops doing work after about an hour

2003-12-04 Thread Gaetano Mendola
, will sleep for 300 secs. [2003-12-04 07:15:19 PM] 504 All DBs checked in: 98814 usec, will sleep for 300 secs. I think is a good Idea put a fflush after: fprintf(LOGOUTPUT, [%s] %s\n, timebuffer, logentry); Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] autovacuum daemon stops doing work after about an hour

2003-12-07 Thread Gaetano Mendola
Gaetano Mendola wrote: Vivek Khera wrote: MTO == Matthew T O'Connor [EMAIL PROTECTED] writes: Then it just sits there. I started it at 11:35am, and it is now 3:30pm. MTO Weird Alphabetically speaking, is vkmlm.public.user_list be the MTO last table in the last schema in the last

Re: [PERFORM] [OFF-TOPIC] - Known maximum size of the

2004-05-07 Thread Gaetano Mendola
redundancy using a RAID 4 or 5, this depend if you need read performances or write performances, in the case of Red Sherif I guess that guys are using RAID 50 ( 0 + 5 ) sets so what you waste is a disk for each set. Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] High load average with PostgreSQL 7.4.2 on debian/ibm eserver.

2004-07-18 Thread Gaetano Mendola
that will not fail with big tables like yours ? if you can post the autovacuum daemon log ( last lines ). Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] [HACKERS] Wrong index choosen?

2004-07-23 Thread Gaetano Mendola
but evidently I have to make it more aggressive, I'm sorry that I can not made him more aggressive only for this table. Thank you all. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Re: [PERFORM] [HACKERS] Wrong index choosen?

2004-07-23 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew T. O'Connor wrote: | Gaetano Mendola wrote: | | Tom Lane wrote: | | Given the nature of the data (login times), I'd imagine that the | problem | | is simply that he hasn't analyzed recently enough. A bump in stats | | target may not be needed

Re: [PERFORM] hardware raid suggestions

2004-07-26 Thread Gaetano Mendola
/Dell_EMC_cx600_specs.pdf and I'm forgotting to have a disk behind... Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Insert are going slower ...

2004-07-26 Thread Gaetano Mendola
is not system wide but let me say for backend... Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Insert are going slower ...

2004-07-26 Thread Gaetano Mendola
decrease the other cpu costs Regards Gaetano Mendola BTW, I live in Paris too, if you need a hand... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Page Miss Hits

2004-08-02 Thread Gaetano Mendola
that is (at least currently) untrue, and that is that PostgreSQL has it's own cache. Are you sure of this ? What is the meaning of the ARC recently introduced then ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Page Miss Hits

2004-08-02 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Marlowe wrote: | On Mon, 2004-08-02 at 10:43, Gaetano Mendola wrote: | |Scott Marlowe wrote: | |On Mon, 2004-08-02 at 02:11, Ioannis Theoharis wrote: | | |Hi, i would like to answer if there is any way in postgres to find the |page miss hits

Re: [PERFORM] Page Miss Hits

2004-08-02 Thread Gaetano Mendola
no one did benchmarks on demostrating with the brute force that ARC is better but on the paper should be. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] pg_autovacuum parameters

2004-08-03 Thread Gaetano Mendola
Matthew T. O'Connor wrote: Lending, Rune wrote: Hello all. I am managing a large database with lots of transactions in different tables. The largest tables have around 5-6 millions tuples and around 5-6 inserts and maybe 2 updates pr day. While the smalest tables have only a few

Re: [PERFORM] NOT IN query takes forever

2004-08-03 Thread Gaetano Mendola
up 128 MB for shared_buffer ( may be you need to instruct your OS to allow that ammount of shared memory usage ) and 24MB for sort_mem. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Performance Bottleneck

2004-08-03 Thread Gaetano Mendola
are not using indexes some where, or may be yes but the planner is not using it... In two words we needs other informations in order to help you. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Temporary tables

2004-08-05 Thread Gaetano Mendola
involving the creation of temporary tables. I seen too this behavior, till I explained that this is a valid sql: select T.* from ( select * from table t where a = 5 ) AS T join foo using ( bar ); show us a typical function that use temporary tables. Regards Gaetano Mendola -BEGIN PGP SIGNATURE

Re: [PERFORM] Tuning queries on large database

2004-08-06 Thread Gaetano Mendola
running under Oracle for about fifteen years. Now I try to replace Oracle by Postgres. Show us the explain analyze on your queries. Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan

Re: [PERFORM] Temporary tables

2004-08-06 Thread Gaetano Mendola
, till I explained that this is a valid sql: select T.* from ( select * from table t where a = 5 ) AS T join foo using ( bar ); show us a typical function that use temporary tables. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill

Re: [PERFORM] [GENERAL] Tuning queries on large database

2004-08-06 Thread Gaetano Mendola
27s Q4 28s 17m20s 6m47s Are you using the same disk for oracle and PG ? Could you post your actual postgresql.conf ? Try also to mount your partition with the option: noatime and try again. Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] Performance Bottleneck

2004-08-06 Thread Gaetano Mendola
Martin Foster wrote: Gaetano Mendola wrote: Martin Foster wrote: I run a Perl/CGI driven website that makes extensive use of PostgreSQL (7.4.3) for everything from user information to formatting and display of specific sections of the site. The server itself, is a dual processor AMD Opteron

Re: [PERFORM] The black art of postgresql.conf tweaking

2004-08-06 Thread Gaetano Mendola
the value MaxClients in your apache configuration Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] The black art of postgresql.conf tweaking

2004-08-06 Thread Gaetano Mendola
of memory available. Am I too optimistic? Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBE81z7UpzwH2SGd4RAuzzAJ98Ze0HQedKaZ/laT7P1OS44FG0CwCfaWkY MAR1TEY1+x61PoXjK/K8Q4Y= =8UmF -END

Re: [PERFORM] Performance Bottleneck

2004-08-06 Thread Gaetano Mendola
Martin Foster wrote: Gaetano Mendola wrote: Let start from your postgres configuration: shared_buffers = 8192 This is really too small for your configuration sort_mem = 2048 wal_buffers = 128 This is really too small for your configuration effective_cache_size = 16000 change

Re: [PERFORM] The black art of postgresql.conf tweaking

2004-08-06 Thread Gaetano Mendola
of space in order to have 200 concurrent connection running but I don't believe that all 200 togheter are allocating space for sort, I have not seen the code but I'm quite confident that the memory for sort is released as soon the sort operation is over, not at the end of connection. Regards Gaetano

Re: [PERFORM] Performance Bottleneck

2004-08-07 Thread Gaetano Mendola
Scott Marlowe wrote: On Fri, 2004-08-06 at 22:02, Martin Foster wrote: Scott Marlowe wrote: On Fri, 2004-08-06 at 17:24, Gaetano Mendola wrote: Martin Foster wrote: Gaetano Mendola wrote: Let start from your postgres configuration: shared_buffers = 8192 This is really too small

Re: [PERFORM] Performance Bottleneck

2004-08-07 Thread Gaetano Mendola
Tom Lane wrote: Martin Foster [EMAIL PROTECTED] writes: Gaetano Mendola wrote: change this values in: shared_buffers = 5 sort_mem = 16084 wal_buffers = 1500 This value of wal_buffers is simply ridiculous. Instead I think is ridiculous a wal_buffers = 8 ( 64KB ) by default. There isn't any

Re: [PERFORM] [HACKERS] fsync vs open_sync

2004-08-11 Thread Gaetano Mendola
: 1749.81 Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBGrSE7UpzwH2SGd4RAoXnAKCHhuw/pWKgY+OD3JcWYMTPDbmgZwCgyqfT +OugUEvUF8usYYrWSGDAnn4= =FAaI -END PGP SIGNATURE

Re: [PERFORM] high load caused by I/O - a hint

2004-08-18 Thread Gaetano Mendola
) and the database works much, much faster. I suggest you to investigate why noapic did the work for you, do you have not well supported device ? At your place also I'd try removing the noapic option and using acpi=noidle Regards Gaetano Mendola ---(end of broadcast

[PERFORM] using an index worst performances

2004-08-19 Thread Gaetano Mendola
With index: 1.400 ms With default_statistic_targer = 200: 1.800 ms tought anyone ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] using an index worst performances

2004-08-19 Thread Gaetano Mendola
Richard Huxton wrote: Gaetano Mendola wrote: Hi all, I'm tring to optimize the following query: http://rafb.net/paste/results/YdO9vM69.html as you can see from the explain after defining the index the performance is worst. If I raise the default_statistic_target to 200 then the performance

Re: [PERFORM] using an index worst performances

2004-08-22 Thread Gaetano Mendola
if I missed the post indicating they were. | | If the plans are the same, it would be interesting to get a profile on | the 2 different cases with that index in place across 100k iterations of | the prepared query. Do you have an advice on the profiler to use ? Regards Gaetano Mendola -BEGIN

[PERFORM] [FUN] Performance increase?

2004-08-24 Thread Gaetano Mendola
Do you think that adopting the chip tuning product postgresql could increase the performances as well ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail

Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?

2004-08-26 Thread Gaetano Mendola
ON. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?

2004-08-27 Thread Gaetano Mendola
be used for indexes that you do not expect to grow or for mostly read-only indexes. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?

2004-08-27 Thread Gaetano Mendola
) to mantain his own correct cluster order. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?

2004-08-27 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Momjian wrote: | Gaetano Mendola wrote: | |Tom Lane wrote: | | Bruce Momjian [EMAIL PROTECTED] writes: | | Agreed. What I am wondering is with our system where every update gets | a new row, how would this help us? I know we try to keep

[PERFORM] ill-planned queries inside a stored procedure

2004-08-28 Thread Gaetano Mendola
this query at execution time ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?

2004-08-28 Thread Gaetano Mendola
instead of jumping. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] ill-planned queries inside a stored procedure

2004-08-28 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Gaetano Mendola [EMAIL PROTECTED] wrote .. | |Hi all, |do you know any clean workaround at ill-planned queries inside a stored |procedure? | I use EXECUTE inside a stored procedure for just this purpose

Re: [PERFORM] fsync vs open_sync

2004-09-04 Thread Gaetano Mendola
/ :-) Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-07 Thread Gaetano Mendola
Pierre-Frédéric Caillaud wrote: Yes, you're right as usual. As usual ? Do you think your father can be wrong on you ? :-) Gaetano ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres

2004-09-12 Thread Gaetano Mendola
Mark Cotner wrote: Requirements: Merge table definition equivalent. We use these extensively. What do you mean with merge table definition equivalent? Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Gaetano Mendola
? Regards Gaetano Mendola These are my times: kernel 2.4.9-e.24smp ( RAID SCSI ): Simple write timing: write0.011544 Compare fsync times on write() and non-write() descriptor: (If the times are similar, fsync() can sync data written on a different descriptor

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: | Gaetano Mendola [EMAIL PROTECTED] writes: | |Now that the argument is already open, why postgres choose |on linux fdatasync? I'm understanding from other posts that |on this platform open_sync is better than fdatasync. | | | AFAIR

Re: [PERFORM] Tryint to match Solaris-Oracle performance with directio?

2004-09-17 Thread Gaetano Mendola
mounting the partition with noatime option ( this however have more impact on performance for read activities ) Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

[PERFORM] 7.4 vs 7.3 ( hash join issue )

2004-09-21 Thread Gaetano Mendola
on the same machine with the same settings. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBULCU7UpzwH2SGd4RAt2ZAKC9FjAKiljRqgaZSZa+p/7N65Cl7ACePWBV TaR2VH1kDSBS7b+kNK4deFo= =X+th

Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

2004-09-22 Thread Gaetano Mendola
Dennis Bjorklund wrote: On Wed, 22 Sep 2004, Gaetano Mendola wrote: Now my question is why the 7.4 choose the hash join ? :-( It looks to me that the marge join is faster because there wasn't really anything to merge, it resulted in 0 rows. Maybe the hash join that is choosen in 7.4 would

Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

2004-09-22 Thread Gaetano Mendola
Dennis Bjorklund wrote: On Wed, 22 Sep 2004, Gaetano Mendola wrote: Limit (cost=10.21..10.21 rows=1 width=24) (actual time=0.885..0.885 rows=0 loops=1) Limit (cost=10.28..10.28 rows=1 width=24) (actual time=0.429..0.429 rows=0 loops=1) These estimated costs are almost the same

Re: [PERFORM] Caching of Queries

2004-09-23 Thread Gaetano Mendola
multiple parameters to PREPARE, for example). Do you mean store different plans for each different histogram segment ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe

Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

2004-09-23 Thread Gaetano Mendola
stuff ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Caching of Queries

2004-09-23 Thread Gaetano Mendola
service environment what you can use is a connection pool ( look for pgpoll IIRC ), if you use a CMS then try to enable the cache in order to avoid to hit the DB for each request. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you

Re: [PERFORM] Caching of Queries

2004-09-23 Thread Gaetano Mendola
means a very huge load, may you provide also the result of vmstat 5 my webserver trash already with -c 120 ! how many connection your postgres can manage ? You have to consider to use a connection pool with that ammount of connections. Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] Caching of Queries

2004-09-25 Thread Gaetano Mendola
be surprised if your lockups are on the OS level, |even; I don't recall that you cited what OS you're using, but I can |imagine locking up Linux 2.4 trying to spawn 300 new processes a |second. Not to mention that a proxy squid mounted in reverse proxy mode will help a lot. Regards Gaetano Mendola

Re: [PERFORM] best statistic target for boolean columns

2004-09-27 Thread Gaetano Mendola
, I didn't understand how the statistics hystogram works. I'm going to take a look at analyze.c Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBWHr07UpzwH2SGd4RAi8nAJoDOa7j

Re: [PERFORM] best statistic target for boolean columns

2004-09-27 Thread Gaetano Mendola
is simple: compare during normal selects the extimated rows and the actual extracted rows then use this free information to refine the histograms. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL

Re: [PERFORM] best statistic target for boolean columns

2004-09-27 Thread Gaetano Mendola
Neil Conway wrote: On Tue, 2004-09-28 at 08:42, Gaetano Mendola wrote: Now I'm reading an article, written by the same author that ispired the magic 300 on analyze.c, about Self-tuning Histograms. If this is implemented, I understood we can take rid of vacuum analyze for mantain up to date

Re: [PERFORM] This query is still running after 10 hours...

2004-09-28 Thread Gaetano Mendola
Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [PERFORM] Interest in perf testing?

2004-09-29 Thread Gaetano Mendola
Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-05 Thread Gaetano Mendola
Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-06 Thread Gaetano Mendola
Xeon, when running on one and both cpus. Here http://www6.tomshardware.com/cpu/20030422/ both were tested and there is a database performance section, unfortunatelly they used MySQL. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain

Re: [PERFORM] [HACKERS] Getting rid of AtEOXact Buffers (was Re: [Testperf-general]

2004-10-17 Thread Gaetano Mendola
[EMAIL PROTECTED] wrote: If the resource owner is always responsible for releasing locked buffers, who releases the locks if the backend crashes? The semaphore undo I hope. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze

Re: [PERFORM] Insert performance, what should I expect?

2004-10-23 Thread Gaetano Mendola
Brock Henry wrote: Any comments/suggestions would be appreciated. Tune also the disk I/O elevator. look at this: http://www.varlena.com/varlena/GeneralBits/49.php Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists

Re: [PERFORM] futex results with dbt-3

2004-10-23 Thread Gaetano Mendola
loss. I proposed weeks ago to see how the CSStorm is affected by stick each backend in one processor ( where the process was born ) using the cpu-affinity capability ( kernel 2.6 ), is this proposal completely out of mind ? Regards Gaetano Mendola ---(end of broadcast

Re: [PERFORM] futex results with dbt-3

2004-10-23 Thread Gaetano Mendola
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: I proposed weeks ago to see how the CSStorm is affected by stick each backend in one processor ( where the process was born ) using the cpu-affinity capability ( kernel 2.6 ), is this proposal completely out of mind ? That was investigated

Re: [PERFORM] futex results with dbt-3

2004-10-23 Thread Gaetano Mendola
of |mind ? | | | I don't see how that would help. The problem is not backends switching | processors, it's the buffermgrlock needing to be swapped between processors. This is not clear to me. What happen if during a spinlock a backend is moved away from one processor to another one ? Regards Gaetano

Re: [PERFORM] [PATCHES] [HACKERS] ARC Memory Usage analysis

2004-10-31 Thread Gaetano Mendola
hope to double this parameter and push postgres to use more RAM. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] seqscan strikes again

2004-11-11 Thread Gaetano Mendola
Jim C. Nasby wrote: I'm wondering if there's any way I can tweak things so that the estimate for the query is more accurate (I have run analyze): Can you post your configuration file ? I'd like to see for example your settings about: random_page_cost and effective_cache_size. Regards Gaetano

Re: [PERFORM] vacuum analyze slows sql query

2004-11-11 Thread Gaetano Mendola
in production code. For sure it will not break the goal: check the existence. Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so

[PERFORM] horizontal partition

2005-02-01 Thread Gaetano Mendola
) (actual time=0.064..0.066 rows=1 loops=1) Index Cond: ((login)::text = 'kalman'::text) Total runtime: 116491.056 ms (16 rows) as you can see the index scan is not used anymore. Do you see any problem on this approach ? Regards Gaetano Mendola

Re: [PERFORM] horizontal partition

2005-02-02 Thread Gaetano Mendola
user_logs_2004 Any reason you didn't use inheritance? I did in that way just to not use postgresql specific feature. I can give it a try and I let you know, however the question remain, why the index usage is lost if used in that way ? Regards Gaetano Mendola ---(end

Re: [PERFORM] Are JOINs allowed with DELETE FROM

2005-02-06 Thread Gaetano Mendola
Steven Rosenstein wrote: DELETE FROM detail JOIN summary ON (summary.id=detail.sum_id) WHERE collect_date='2005-02-05'; DELETE FROM detail WHERE detail.sum_id in ( select id from summary ) AND collect_date='2005-02-05'; Regards Gaetano Mendola ---(end of broadcast

[PERFORM] bad performances using hashjoin

2005-02-20 Thread Gaetano Mendola
Hi all, I'm stuck in a select that use the hash join where should not: 6 seconds vs 0.3 ms !! If you need other info in order to improve the planner, let me know. Regards Gaetano Mendola empdb=# explain analyze SELECT id_sat_request empdb-#FROM sat_request sr, empdb

Re: [PERFORM] bad performances using hashjoin

2005-02-21 Thread Gaetano Mendola
Tom Lane wrote: but this behavior isn't reproduced in the later message, so I wonder if it wasn't an artifact of something else taking a chunk of time. I think is due the fact that first queries were performed in peakhours. Regards Gaetano Mendola ---(end

Re: [PERFORM] Effects of IDLE processes

2005-02-21 Thread Gaetano Mendola
Christopher Browne wrote: After a long battle with technology, Gaetano Mendola [EMAIL PROTECTED], an earthling, wrote: JM wrote: Hi ALL, I was wondering if there is a DB performance reduction if there are a lot of IDLE processes. 30786 ?S 0:00 postgres: user1 gmadb

[PERFORM] is pg_autovacuum so effective ?

2005-02-22 Thread Gaetano Mendola
it in a more aggressive way ? May be I'm missing something. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] is pg_autovacuum so effective ?

2005-02-22 Thread Gaetano Mendola
| 200 max_fsm_relations | 1000 at least after a vacuum full I see that these numbers are an overkill... REgards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command

Re: [PERFORM] is pg_autovacuum so effective ?

2005-02-22 Thread Gaetano Mendola
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: I'm using ony pg_autovacuum. I expect that disk usage will reach a steady state but is not. PG engine: 7.4.5 One data point doesn't prove that you're not at a steady state. I do a graph about my disk usage and it's a ramp since one

Re: [PERFORM] is pg_autovacuum so effective ?

2005-02-28 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Schaber wrote: Hi, Gaetano, Gaetano Mendola schrieb: I have the same requirement too. Actually pg_autovacuum can not be instructed per table so some time the global settings are not good enough. I have a table of logs with 6 milions

Re: [PERFORM] Inheritence versus delete from

2005-03-01 Thread Gaetano Mendola
in a single transaction 60+ million rows is not feseable, at least on my 1 GB ram, 2 way CPU box. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] bad plan

2005-03-08 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Huxton wrote: Gaetano Mendola wrote: running a 7.4.5 engine, I'm facing this bad plan: empdb=# explain analyze SELECT name,url,descr,request_status,url_status,size_mb,estimated_start,request_time_stamp empdb-#FROM

[PERFORM] Bad Performance[2]

2005-03-14 Thread Gaetano Mendola
AS id_package, id_programAS id_program, internal_position AS internal_position, estimated_start AS estimated_start FROM sequences ; Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG

[PERFORM] Wrong plan sequential scan instead of an index one

2007-03-30 Thread Gaetano Mendola
much choose a sequential scan due to 19 estimated rows when with 4 estimated does a correct index scan ? Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Re: [PERFORM] Wrong plan sequential scan instead of an index one

2007-03-30 Thread Gaetano Mendola
for postgresql how fast your disks are, the lower the faster. Could this setting be changed to 2 as default rather than 4? I have tuned that number already at 2.5, lowering it to 2 doesn't change the plan. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment

Re: [PERFORM] Wrong plan sequential scan instead of an index one

2007-03-30 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Huxton wrote: Gaetano Mendola wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, take a look at those plans: test=# explain analyze SELECT COUNT(id) FROM t_oa_2_00_card WHERE pvcp in (select id from l_pvcp where value ilike

Re: [PERFORM] Wrong plan sequential scan instead of an index one

2007-03-30 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Fuhr wrote: On Fri, Mar 30, 2007 at 12:08:26PM +0200, Gaetano Mendola wrote: Claus Guttesen wrote: Try changing random_page_cost from the default 4 to 2 in postgresql.conf: random_page_cost = 2 I have tuned that number already at 2.5

Re: [PERFORM] Wrong plan sequential scan instead of an index one

2007-03-30 Thread Gaetano Mendola
for LIKE, ILIKE, and regular expression operations (Tom) I will try same select on a 8.2 ( that one was a 8.1 ) and I'll let you know. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

[PERFORM] Re: Wrong plan sequential scan instead of an index one [8.2 solved it]

2007-04-02 Thread Gaetano Mendola
: (t_oa_2_00_card.pvcp = l_pvcp.id) Total runtime: 23.491 ms (10 rows) I had to lower the random_page_cost = 2.5 in order to avoid the sequential scan on the big table t_oa_2_00_card. this is a +1 to update our engines to a 8.2. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5

Re: [PERFORM] large tables and simple = constant queries using indexes

2008-04-10 Thread Gaetano Mendola
John Beaver wrote: - Trying the same constant a second time gave an instantaneous result, I'm guessing because of query/result caching. AFAIK no query/result caching is in place in postgres, what you are experiencing is OS disk/memory caching. Regards Gaetano Mendola -- Sent via pgsql

[PERFORM] shared_buffers in 8.2.x

2008-04-10 Thread Gaetano Mendola
Hi all, specifing as shared_buffers = 26800 in 8.2.x will this value accepted like in the 8.1.x series and then 26800*8192 bytes = 209 MB or 26800 bytes (not being specified the memory unit)? Regards Gaetano Mendola -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org

[PERFORM] shared_buffers performance

2008-04-14 Thread Gaetano Mendola
. Is this something expected or I'm looking in the wrong direction? I'm going to perform same tests without using the -S option in pgbench but being a time expensive operation I would like to ear your opinion first. Regards Gaetano Mendola -- Sent via pgsql-performance mailing list (pgsql-performance

  1   2   >