Hi,
Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh 9 require a
lot of lib's) and set the configuration sent by Chris. Now the query results in 6.3
sec waooo. I m thinking that why the 7.1 process aggregate slowly. Anyway.
I still have to go for 2 sec result and now
On Thursday 19 February 2004 14:31, Saleem Burhani Baloch wrote:
Hi,
Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh
9 require a lot of lib's) and set the configuration sent by Chris. Now the
query results in 6.3 sec waooo. I m thinking that why the 7.1 process
Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 (
rh 9 require a lot of lib's) and set the configuration sent by Chris.
Now the query results in 6.3 sec waooo. I m thinking that why the 7.1
process aggregate slowly. Anyway.
I'm glad we could help you Saleem :)
We knew
Title: Message
Hello,
Has anyone
designed/implemented postgresql server on storage networks?
Are there any design
considerations?
Are there any
benchmarks for storage products (HBAs, Switches, Storage
Arrays)?
Any recommendation
on the design, resources, references, keeping PG in mind?
Anjan,
Has anyone designed/implemented postgresql server on storage networks?
Yes, Zapatec.com runs their stuff this way. Probably others as well.
Are there any design considerations?
I don't know. Probably.
Are there any benchmarks for storage products (HBAs, Switches, Storage
Josh Berkus wrote:
Anjan,
Has anyone designed/implemented postgresql server on storage networks?
Yes, Zapatec.com runs their stuff this way. Probably others as well.
Are there any design considerations?
I don't know. Probably.
Are there any benchmarks for storage products
Saleem Burhani Baloch kirjutas N, 19.02.2004 kell 11:01:
Hi,
Thanks every one for helping me. I have upgraded to 7.4.1 on
redhat 8 ( rh 9 require a lot of lib's) and set the configuration
sent by Chris. Now the query results in 6.3 sec waooo. I m thinking
that why the 7.1 process
Jeff Boes writes
# explain select link_id from links l join clm_tmp_links t on
(fn_urlrev(l.path_base) = t.rev_path_base);
executes in 59.8 seconds!
Now the odd part: if I change the query to this:
# explain analyze select link_id from links l join clm_tmp_links t on
Tom,
event_date = 'end-date' AND (event_date + duration) = 'start-date'
AND event_date = 'start-date' - 'max-duration'
Great suggestion! We're down to 160ms, from about 370ms with my subselect
workaround. Thanks!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
