2007/3/28, Tom Lane <[EMAIL PROTECTED]>:
"Daniel Cristian Cruz" <[EMAIL PROTECTED]> writes:
> 2007/3/28, chris smith <[EMAIL PROTECTED]>:
>>> Total runtime: 13.844 ms
>>
>> Why bother?
> Because faster could be better in a very busy system.
If you are concerned about global performance improve
"Daniel Cristian Cruz" <[EMAIL PROTECTED]> writes:
> 2007/3/28, chris smith <[EMAIL PROTECTED]>:
>>> Total runtime: 13.844 ms
>>
>> Why bother?
> Because faster could be better in a very busy system.
If you are concerned about global performance improvement, quit worrying
about this micro-detail
Daniel Cristian Cruz wrote:
Hi all.
I would like to speed up this query:
EXPLAIN ANALYZE
SELECT
relid,schemaname,relname,seq_scan,seq_tup_read,idx_scan,idx_tup_fetch,n_tup_ins,n_tup_upd,n_tup_del
FROM pg_stat_user_tables;
Although optimizing for 13ms is a little silly imo, you could prob
2007/3/28, chris smith <[EMAIL PROTECTED]>:
> Total runtime: 13.844 ms
Why bother?
Because faster could be better in a very busy system.
--
Daniel Cristian Cruz
Analista de Sistemas
I would like to speed up this query:
Total runtime: 13.844 ms
Why bother?
It's running in less than 14 milliseconds.
--
Postgresql & php tutorials
http://www.designmagick.com/
---(end of broadcast)---
TIP 7: You can help support the Postgr
Hi all.
I would like to speed up this query:
EXPLAIN ANALYZE
SELECT
relid,schemaname,relname,seq_scan,seq_tup_read,idx_scan,idx_tup_fetch,n_tup_ins,n_tup_upd,n_tup_del
FROM pg_stat_user_tables;
QUERY PLAN
