Re: [GENERAL] Statistics on index usage

On Tue, Nov 1, 2016 at 10:43 AM, François Battail < francois.batt...@sipibox.fr> wrote: > Dear List, > > does pgsql maintains statistics on index usage? I mean just a counter > for each index in the database, incremented each time time it is used. > It would be useful to help cleaning almost unuse

Re: [GENERAL] Statistics on index usage

On Tue, Nov 1, 2016 at 8:43 AM, François Battail wrote: > Dear List, > > does pgsql maintains statistics on index usage? I mean just a counter > for each index in the database, incremented each time time it is used. > It would be useful to help cleaning almost unused index and to avoid > poisoning

[GENERAL] Statistics on index usage

Dear List, does pgsql maintains statistics on index usage? I mean just a counter for each index in the database, incremented each time time it is used. It would be useful to help cleaning almost unused index and to avoid poisoning the global cache. I've found nothing so far but may be I've been m

Re: [GENERAL] Statistics query

On 04/10/2013 10:31 AM, Chris Curvey wrote: On Wed, Apr 10, 2013 at 12:30 PM, Steve Crawford > wrote: I'm seeking ideas on the best way to craft the following query. I've stripped everything down to the bare essentials and simplified it below

Re: [GENERAL] Statistics query

On Wed, Apr 10, 2013 at 12:30 PM, Steve Crawford < scrawf...@pinpointresearch.com> wrote: > I'm seeking ideas on the best way to craft the following query. I've > stripped everything down to the bare essentials and simplified it below. > > Input data has a timestamp (actually an int received from

[GENERAL] Statistics query

I'm seeking ideas on the best way to craft the following query. I've stripped everything down to the bare essentials and simplified it below. Input data has a timestamp (actually an int received from the system in the form of a Unix epoch), a unit identifier and a status: event_time | unit_i

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

It seems that we are currently running 8.4.3 on the server we are encountering the problem. Will upgrade to 8.4.9 and then will come back with a test case if we still see the issue Thanks again for your help. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Statistics-

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

tim_wilson writes: > When you say recent releases, does that include 8.4? 8.4.9 and later --- anything including this commit: Author: Tom Lane Branch: master Release: REL9_1_BR [b4b6923e0] 2011-05-30 17:06:52 -0400 Branch: REL9_0_STABLE Release: REL9_0_5 [73bd34c81] 2011-05-30 17:07:07 -0400 B

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

Thanks for the reply Tom, will try and construct test case. Have been unable to replicate in a simple test the sort of updates that the table out in the wild is seeing, so may impact that issue of vacuum finding unrepresentative sample, maybe. Will try harder! When you say recent releases, does

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

tim_wilson writes: > This drift gets more confusing. In recent releases, reltuples (and relpages) are updated via a "moving average" calculation that is meant to converge on the true value over time. The reason vacuum has to act that way is that it typically doesn't scan the whole table anymore

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

On 12/06/2012 06:45 PM, tim_wilson wrote: 86% of the updates are HOT updates! The difference between the first and second line of this image above is that 366 updates happened of which 299 where HOT. And a vacuum on the t

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

86% of the updates are HOT updates! The difference between the first and second line of this image above is that 366 updates happened of which 299 where HOT. And a vacuum on the table was run. Look at the retuples number c

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

On 12/06/2012 06:13 PM, tim_wilson wrote: This drift gets more confusing. My small table A (60K rows) is not being inserted to (except one or two rows) it is getting thousands of updates a minute. Analyze and vacuum on the table are running regularly. But sometimes ,every time the vacuum runs th

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

I am also seeing a drift in the n_live_tup value compared to actual row count on the table on PG9.0.6 It drifts after a vacuum , you can bring it back closer to the actual number by running ANALYSE several times, you can lock it back into the right value with a vacuum full, but then if you run a v

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

> Andreas Brandl writes: > >> The planner doesn't use n_live_tup; > > > I'm just curious: where does the planner take the (approximate) > > row-count from? > > It uses the tuple density estimated by the last vacuum or analyze > (viz, > reltuples/relpages) and multiplies that by the current relat

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

Andreas Brandl writes: >> The planner doesn't use n_live_tup; > I'm just curious: where does the planner take the (approximate) row-count > from? It uses the tuple density estimated by the last vacuum or analyze (viz, reltuples/relpages) and multiplies that by the current relation size. There a

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

Hi, > Andreas Brandl writes: > > we're currently investigating a statistics issue on postgres. We > > have some tables which frequently show up with strange values for > > n_live_tup. If you compare those values with a count on that > > particular table, there is a mismatch of factor 10-30. This

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

Andreas Brandl writes: > we're currently investigating a statistics issue on postgres. We have some > tables which frequently show up with strange values for n_live_tup. If you > compare those values with a count on that particular table, there is a > mismatch of factor 10-30. This causes the p

[GENERAL] Statistics mismatch between n_live_tup and actual row count

Hi, we're currently investigating a statistics issue on postgres. We have some tables which frequently show up with strange values for n_live_tup. If you compare those values with a count on that particular table, there is a mismatch of factor 10-30. This causes the planner to come up with very

Re: [GENERAL] Statistics collector failure messages on startup

Christophe Pettus writes: > On PostgreSQL 9.0.1, on Ubuntu 10.04.2, I'm seeing these on startup: > 2011-09-22 19:22:15.984 UTC,,,6066,,4e7b8ae7.17b2,1,,2011-09-22 19:22:15 > UTC,,0,LOG,08006,"test message did not get through on socket for statistics > collector","" > 2011-09-22 19:22:15.

[GENERAL] Statistics collector failure messages on startup

On PostgreSQL 9.0.1, on Ubuntu 10.04.2, I'm seeing these on startup: 2011-09-22 19:22:15.984 UTC,,,6066,,4e7b8ae7.17b2,1,,2011-09-22 19:22:15 UTC,,0,LOG,08006,"test message did not get through on socket for statistics collector","" 2011-09-22 19:22:15.984 UTC,,,6066,,4e7b8ae7.17b2,2,,201

Re: [GENERAL] Statistics about Streaming Replication deployments in production

On Thu, Jul 28, 2011 at 12:03 PM, Samba wrote: > I think one year is sufficient time for any product/feature to be thoroughly > tested for all its strengths and weaknesses; so would it be too much to ask > the vast postgres customer base about their experiences with streaming > replication, the g

Re: [GENERAL] Statistics about Streaming Replication deployments in production

Dne 28.7.2011 13:03, Samba napsal(a): > One concern that is being coined by the our management team is regarding > the relative stability and 'industrial-strength' of streaming > replication. Considering that this feature is just one year old, doubts > are expressed about > > * data integrity --

[GENERAL] Statistics about Streaming Replication deployments in production

Hi all, We, at Avaya India, have been using postgres for a few years and are very happy with the stability and performance of the system. We would want to utilise the newly released streaming replication feature to build a master-(multiple)slave based geographically redundant setup . We ship to our

[GENERAL] Statistics and PostgreSQL: Streaming Webcast tonight

Folks, For those of you who can't attend in person, we'll be streaming audio and video and having a chat for tonight's SFPUG meeting on how the planner uses statistics. Video: http://media.postgresql.org/sfpug/streaming Chat: irc://irc.freenode.net/sfpug Cheers, David. -- David Fetter http:

Re: [GENERAL] Statistics Data archiving with Postgres

Pascal Cohen wrote: > But to sum up we would like to collect statistics (write mostly tables, > high volume generation, data not critical) on an application usage on a > read mostly DB with the least impact on this DB perfs. ANn we would also > like to be able to archive outside the DB, the old co

[GENERAL] Statistics Data archiving with Postgres

Hello We are developing an application and would like to compute statistics on it in order: - to have a better understanding of what is used mostly in our application to model at best our load test scenarios. - to get information on the usage of the application for other departments. The probl

Re: [GENERAL] statistics collector process is thrashing my cpu

William Temperley wrote: > On Fri, May 9, 2008 at 2:55 PM, Magnus Hagander <[EMAIL PROTECTED]> > wrote: > > > William Temperley wrote: > > > On Thu, May 8, 2008 at 6:14 PM, Magnus Hagander > > > <[EMAIL PROTECTED]> wrote: > > > > William Temperley wrote: > > > >> > > > > > >> > > Any ideas why t

Re: [GENERAL] statistics collector process is thrashing my cpu

On Fri, May 9, 2008 at 2:55 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote: > William Temperley wrote: > > On Thu, May 8, 2008 at 6:14 PM, Magnus Hagander <[EMAIL PROTECTED]> > > wrote: > > > William Temperley wrote: > > >> > > > > >> > > Any ideas why this might be happening, and how I can stop

Re: [GENERAL] statistics collector process is thrashing my cpu

William Temperley wrote: > On Thu, May 8, 2008 at 6:14 PM, Magnus Hagander <[EMAIL PROTECTED]> > wrote: > > William Temperley wrote: > >> > > > >> > > Any ideas why this might be happening, and how I can stop it? > >> > > >> > It'd be interesting to know what the stats collector is actually > >>

Re: [GENERAL] statistics collector process is thrashing my cpu

On Thu, May 8, 2008 at 6:14 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote: > William Temperley wrote: >> > > >> > > Any ideas why this might be happening, and how I can stop it? >> > >> > It'd be interesting to know what the stats collector is actually >> > doing. Could you, using Process Explor

Re: [GENERAL] statistics collector process is thrashing my cpu

William Temperley wrote: > > > > > > Any ideas why this might be happening, and how I can stop it? > > > > It'd be interesting to know what the stats collector is actually > > doing. Could you, using Process Explorer or a debugger, get a stack > > trace from that process while it's in the trashi

Re: [GENERAL] statistics collector process is thrashing my cpu

> > > > Any ideas why this might be happening, and how I can stop it? > > It'd be interesting to know what the stats collector is actually doing. > Could you, using Process Explorer or a debugger, get a stack trace from > that process while it's in the trashing state? > > //Magnus > Certainl

Re: [GENERAL] statistics collector process is thrashing my cpu

William Temperley wrote: > Dear All > > Sometimes postgres.exe will thrash one of the cores and won't stop > until I kill the process. I know it's the statistics collector as I > get this message when I kill the process: > "statistics collector process (PID 172) exited with exit code 1" > Nothing

[GENERAL] statistics collector process is thrashing my cpu

Dear All Sometimes postgres.exe will thrash one of the cores and won't stop until I kill the process. I know it's the statistics collector as I get this message when I kill the process: "statistics collector process (PID 172) exited with exit code 1" Nothing other than this app is accessing my PG

Re: [GENERAL] Statistics collection question

Well first question: how can I check if autovacuum is working? On 04/09/2007, Tom Lane <[EMAIL PROTECTED]> wrote: > "Phoenix Kiula" <[EMAIL PROTECTED]> writes: > > Basically, what I am missing is some info on actually tweaking the > > postgresql.conf to suit my system. > > No, that's *not* what y

Re: [GENERAL] Statistics collection question

On Mon, Sep 10, 2007 at 07:05:54PM -, [EMAIL PROTECTED] wrote: > When I do a "select * from pg_locks", some of them show up as > "Exclusive Lock". This I suppose means that the whole table is locked, > right? How can I find from the "transaction id" which precise SQL > statement is taking this

Re: [GENERAL] Statistics collection question

On Sep 4, 10:54 pm, [EMAIL PROTECTED] (Tom Lane) wrote: > "Phoenix Kiula" <[EMAIL PROTECTED]> writes: > > Would appreciate any help. Why do indexed queries take so much time? > > It's a simple DB with "10 relations" including tables and indexes. > > Simple inserts and updates, about 5000 a day, but

Re: [GENERAL] Statistics collection question

"Phoenix Kiula" <[EMAIL PROTECTED]> writes: > Would appreciate any help. Why do indexed queries take so much time? > It's a simple DB with "10 relations" including tables and indexes. > Simple inserts and updates, about 5000 a day, but non-trivial > concurrent selects (about 45 million a day). Work

Re: [GENERAL] Statistics collection question

"Phoenix Kiula" <[EMAIL PROTECTED]> writes: > Basically, what I am missing is some info on actually tweaking the > postgresql.conf to suit my system. No, that's *not* what you're missing. I'm not sure what the problem is in your system, but I'm pretty sure that everything you have frantically bee

Re: [GENERAL] Statistics collection question

Phoenix Kiula wrote: > On 04/09/07, Tom Lane <[EMAIL PROTECTED]> wrote: >> I'm wondering about some transaction taking exclusive lock on the table >> and sitting on it for a minute or so, and also about network problems >> delaying transmission of data to the client. >> > How can I check what is ca

Re: [GENERAL] Statistics collection question

On Tue, Sep 04, 2007 at 03:07:41PM +0800, Phoenix Kiula wrote: > How can I check what is causing the lack? When I restart pgsql it goes > away. The log is empty for a day or too (I'm only logging errors or > slow queries) and the queries are super fast, but after a day it > starts filling up with a

Re: [GENERAL] Statistics collection question

enix Kiula Sent: Tue 9/4/2007 1:07 AM To: Tom Lane Cc: Richard Broersma Jr; Alban Hertroys; Postgres General Subject: Re: [GENERAL] Statistics collection question On 04/09/07, Tom Lane <[EMAIL PROTECTED]> wrote: > "Phoenix Kiula" <[EMAIL PROTECTED]> writes: > > On 0

Re: [GENERAL] Statistics collection question

On 04/09/07, Tom Lane <[EMAIL PROTECTED]> wrote: > "Phoenix Kiula" <[EMAIL PROTECTED]> writes: > > On 04/09/07, Richard Broersma Jr <[EMAIL PROTECTED]> wrote: > >> Thats odd, I wonder why the EXPLAIN ANALYZE time id some much less that > >> the logged select > >> statement times? > > > Because the

Re: [GENERAL] Statistics collection question

"Phoenix Kiula" <[EMAIL PROTECTED]> writes: > On 04/09/07, Richard Broersma Jr <[EMAIL PROTECTED]> wrote: >> Thats odd, I wonder why the EXPLAIN ANALYZE time id some much less that the >> logged select >> statement times? > Because the statement has been executed and is in the cache. That answer

Re: [GENERAL] Statistics collection question

On 04/09/07, Richard Broersma Jr <[EMAIL PROTECTED]> wrote: > --- Phoenix Kiula <[EMAIL PROTECTED]> wrote: > > LOG: duration: 93473.282 ms statement: select t_info, dstats, id > > from trades where t_alias = '17huv' and status = 'Y' > > > > --- > > > > Index Scan using trades

Re: [GENERAL] Statistics collection question

--- Phoenix Kiula <[EMAIL PROTECTED]> wrote: > LOG: duration: 93473.282 ms statement: select t_info, dstats, id > from trades where t_alias = '17huv' and status = 'Y' > > --- > > Index Scan using trades_unique_t_alias on trades (cost=0.00..3.41 > Time: 2.990 ms Thats o

Re: [GENERAL] Statistics collection question

On 03/09/07, Alban Hertroys <[EMAIL PROTECTED]> wrote: > Phoenix Kiula wrote: > As I understand it it's a sample of how the data is distributed. > Probably it's based on statistical mathematics that specifies a minimum > size for a representive sample of a given data set. It boils down to: > "If yo

Re: [GENERAL] Statistics collection question

Phoenix Kiula wrote: > Lots of posts here in reponse to performance question have the > recommendation "increase the stats on that column". From whatever > succint reading is made available on the postgres site, I gather that > this aids the planner in getting some info about some of the data. Am >

Re: [GENERAL] Statistics collection question

Phoenix Kiula escribió: > On 03/09/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Phoenix Kiula" <[EMAIL PROTECTED]> writes: > > > most_common_vals will (and should) be empty if there aren't actually any > > common values, but aren't you getting a histogram? Exactly what > > performance do you thin

Re: [GENERAL] Statistics collection question

On 03/09/07, Tom Lane <[EMAIL PROTECTED]> wrote: > "Phoenix Kiula" <[EMAIL PROTECTED]> writes: > most_common_vals will (and should) be empty if there aren't actually any > common values, but aren't you getting a histogram? Exactly what > performance do you think will be improved? Lots of posts

Re: [GENERAL] Statistics collection question

"Phoenix Kiula" <[EMAIL PROTECTED]> writes: > A couple of questions about the "most_common_vals" stuff in pg_stats > for a high traffic table: > 1. Can I tell the stats collector to collect only values of a column > where a certain regex is matched? Not directly, but you could set up a partial in

[GENERAL] Statistics collection question

A couple of questions about the "most_common_vals" stuff in pg_stats for a high traffic table: 1. Can I tell the stats collector to collect only values of a column where a certain regex is matched? It is currently collecting the 500 values where most of them are values that I don't want, so it's p

Re: [GENERAL] statistics monitoring performance improvment -- 8.1 as well as 8.2 ?

On Jun 18, 2007, at 16:23 , [EMAIL PROTECTED] wrote: Did those improvements ever get applied to postgres 8.1.y ? perhaps in 8.1.8 or 8.1.9 ? Check the release notes for those versions, or possibly CVS. Most likely not, as usually only bug fixes are back patched. Michael Glaesemann grzm s

[GENERAL] statistics monitoring performance improvment -- 8.1 as well as 8.2 ?

Last year, there was a problem involving stats_command_string in early 8.1.x http://archives.postgresql.org/pgsql-bugs/2006-01/msg00151.php I see mentions of performance improvements in the statistics collector for 8.2.x http://www.postgresql.org/docs/8.2/static/release-8-2.html "I

Re: [GENERAL] statistics on CRUD operations

""Simon Riggs"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mon, 2007-06-18 at 12:35 +0300, Sabin Coanda wrote: > >> Is somewhere a system table providing statistic counters of CRUD >> operations >> against custom databases ? > > pg_stat_user_tables > > http://www.postgresql

Re: [GENERAL] statistics on CRUD operations

On Mon, 2007-06-18 at 12:35 +0300, Sabin Coanda wrote: > Is somewhere a system table providing statistic counters of CRUD operations > against custom databases ? pg_stat_user_tables http://www.postgresql.org/docs/8.2/static/monitoring-stats.html#MONITORING-STATS-VIEWS -- Simon Riggs

[GENERAL] statistics on CRUD operations

Hi there, Is somewhere a system table providing statistic counters of CRUD operations against custom databases ? TIA, Sabin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Statistics

On Fri, 2007-03-09 at 14:40 -0300, Ezequias Rodrigues da Rocha wrote: > > On Fri, 2007-03-09 at 14:22 -0300, Ezequias Rodrigues da Rocha wrote: > Does someone have statistcs from PostgreSQL ? Numbers from the list, > performance statistics. I must argue with another person the idea of > > do n

[GENERAL] Statistics

On Fri, 2007-03-09 at 14:22 -0300, Ezequias Rodrigues da Rocha wrote: Does someone have statistcs from PostgreSQL ? Numbers from the list, performance statistics. I must argue with another person the idea of do not put Oracle in our organization. We are quite well with postgresql and I have no p

Re: [GENERAL] statistics buffer is full on heavily loaded 8.1.4 db.

Oops, knew I forgot something. Here are the settings from our postgresql.conf I beilive it's set to allow autovac to work and nothing else. # - Query/Index Statistics Collector - stats_start_collector = on stats_command_string = off stats_block_level = off stats_row_level = on #stats_reset_o

Re: [GENERAL] statistics buffer is full on heavily loaded 8.1.4 db.

Eci Souji wrote: We have a 4x 2.4ghz Opteron box w/ 8 gigs of ram running a very busy pg 8.1.4 server. Upon startup we see around 15-20 "statistics buffer is full" messages and they repeat at random times throughout the day. During peak times the box sometimes seems to grind to a halt. Any t

Re: [GENERAL] statistics buffer is full on heavily loaded 8.1.4 db.

Do you have stats_command_string=onin postgresql.conf as that might cause this error.If it is truned on please turn it off and then try starting your server.Thanks,-- Shoaib MirEnterpriseDB ( www.enterprisedb.com)On 9/20/06, Eci Souji <[EMAIL PROTECTED]> wrote: We have a 4x 2.4ghz Opteron box w/ 8

[GENERAL] statistics buffer is full on heavily loaded 8.1.4 db.

We have a 4x 2.4ghz Opteron box w/ 8 gigs of ram running a very busy pg 8.1.4 server. Upon startup we see around 15-20 "statistics buffer is full" messages and they repeat at random times throughout the day. During peak times the box sometimes seems to grind to a halt. Any thoughts? - E -

Re: [GENERAL] Statistics and Indexes

[EMAIL PROTECTED] wrote: > Hi > > I am from a MSSQL background and am trying to understand something about > statistics in PostgreSQL. > > Question 1: > In MSSQL, if you create an index (and you are using MSSQL's default > settings) the Server will automatically create appropriate statistics for

[GENERAL] Statistics and Indexes

Hi I am from a MSSQL background and am trying to understand something about statistics in PostgreSQL. Question 1: In MSSQL, if you create an index (and you are using MSSQL's default settings) the Server will automatically create appropriate statistics for you. Does this happen in PostgreSQL? Or s

Re: [GENERAL] Statistics with PostgreSQL

> Mean is just sum(col)/count(col) You can also just use avg(col). Either way, be careful because nulls may not be treated as you want for such calculations. The stats package R can access Postgres databases, and can be used for robust statistical analyses of the data. See: http://sourceforge

Re: [GENERAL] Statistics with PostgreSQL

/* On the test stub: */ [snip] double data[30]; int main(void) { size_t i; size_t size = sizeof(data) / sizeof(data[0]); for (i = 0; i < size; i++) { data[i] = rand(); } for (i = 0; i < size; i++) { cout << data[i] << end

Re: [GENERAL] Statistics with PostgreSQL

return 0; } -----Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hrishikesh Deshmukh Sent: Friday, March 18, 2005 10:37 AM To: Postgresql-General Subject: [GENERAL] Statistics with PostgreSQL Hi All, Is there a way to simple statistics like mean/media

Re: [GENERAL] Statistics with PostgreSQL

On Fri, Mar 18, 2005 at 01:37:10PM -0500, Hrishikesh Deshmukh wrote: > Hi All, > > Is there a way to simple statistics like mean/median/mode in > PostgreSQL. I have tables like PsetID | IntensityValue. I want to > find out mean (intensityValue) of some PsetID(s)?! > Any urls/pointers/books would

[GENERAL] Statistics with PostgreSQL

Hi All, Is there a way to simple statistics like mean/median/mode in PostgreSQL. I have tables like PsetID | IntensityValue. I want to find out mean (intensityValue) of some PsetID(s)?! Any urls/pointers/books would be a big help. Thanks, Hrishi ---(end of broadcast)-

Re: [GENERAL] Statistics on a table

Stephan Szabo <[EMAIL PROTECTED]> writes: >> statistic ( n_distinct in particular) records for one of my columns, >> greatly under calculated it saying: >> 49726, but in reality 33409816. >> is it any way how I can improve that? > You might see if raising the statistics target with ALTER TABLE ALT

Re: [GENERAL] Statistics on a table

On Tue, 8 Jul 2003, Maksim Likharev wrote: > Hi, > I just found very interesting situation, > statistic ( n_distinct in particular) records for one of my columns, > greatly under calculated it saying: > > 49726, but in reality 33409816. > > So planer never choose index but rather using table scan

[GENERAL] Statistics on a table

Hi, I just found very interesting situation, statistic ( n_distinct in particular) records for one of my columns, greatly under calculated it saying: 49726, but in reality 33409816. So planer never choose index but rather using table scan, and query never returns, is it any way how I can improve

[GENERAL] statistics

Hi, is there a way to get statistuics from postgres, like the amount of requests it handled, or the amount of connections it had the last 10 min. Just curious so I can link it with Mysql. May pg_statistics is the solution for my problem, but don;t get it atm. ys, -- -- Ramses Smeyers <[EMAIL