[PERFORM] Execution Plan

2010-07-23 Thread std pik
Hi all.. Can any one help me? I'd like to know how can we get the following information in PostgreSQL: Execution plan The I/O physical reads and logical reads, CPU consumption, number of DB block used, and any other information relevant to performance. Taking into consideration that these

Re: [PERFORM] Execution Plan

2010-07-23 Thread Pavel Stehule
Hello 2010/7/23 std pik std...@gmail.com: Hi all.. Can any one help me? I'd like to know how can we get the following information in PostgreSQL: Execution plan The I/O physical reads and logical reads, CPU consumption, number of DB block used, and any other information relevant to

Re: [PERFORM] Using more tha one index per table

2010-07-23 Thread Torsten Zühlsdorff
Craig James schrieb: A useful trick to know is that if you replace the version number with current, you'll get to the latest version most of the time (sometimes the name of the page is changed between versions, too, but this isn't that frequent). The docs pages could perhaps benefit from an

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Joshua Tolley
On Thu, Jul 22, 2010 at 02:44:04PM -0700, Scott Carey wrote: On Jul 22, 2010, at 11:36 AM, Robert Haas wrote: On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer cr...@postnewspapers.com.au wrote: So rather than asking should core have a connection pool perhaps what's needed is to ask what can

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Joshua D. Drake
On Thu, 2010-07-22 at 20:56 +0100, Hannu Krosing wrote: Let's extend this shall we: Avoid adding yet another network hop postgreSQL is multi-process, so you either have a separate pooler process or need to put pooler functionality in postmaster, bothw ways you still have a two-hop

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Robert Haas
On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing ha...@krosing.net wrote: On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote: On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing ha...@krosing.net wrote: On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote: On Mon, Jul 12, 2010 at 6:58 AM, Craig

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Hannu Krosing
On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote: On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing ha...@krosing.net wrote: On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote: On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer cr...@postnewspapers.com.au wrote: So rather than asking

Re: [PERFORM] Using more tha one index per table

2010-07-23 Thread Craig James
On 7/23/10 2:22 AM, Torsten Zühlsdorff wrote: Craig James schrieb: A useful trick to know is that if you replace the version number with current, you'll get to the latest version most of the time (sometimes the name of the page is changed between versions, too, but this isn't that frequent).

Re: [PERFORM] Strange explain on partitioned tables

2010-07-23 Thread Gerald Fontenay
The PostgreSQL partitioning system is aimed to support perhaps a hundred inherited tables. You can expect to get poor performance on queries if you create 1000 of them. Hi, Why is that you would expect poor performance for say 1000 or more? I have a ~1000 inherited tables and I don't see

Re: [PERFORM] Strange explain on partitioned tables

2010-07-23 Thread Joshua D. Drake
On Fri, 2010-07-23 at 15:03 -0700, Gerald Fontenay wrote: The PostgreSQL partitioning system is aimed to support perhaps a hundred inherited tables. You can expect to get poor performance on queries if you create 1000 of them. Hi, Why is that you would expect poor performance for

Re: [PERFORM] Strange explain on partitioned tables

2010-07-23 Thread Greg Smith
Gerald Fontenay wrote: The PostgreSQL partitioning system is aimed to support perhaps a hundred inherited tables. You can expect to get poor performance on queries if you create 1000 of them. Why is that you would expect poor performance for say 1000 or more? When the query planner

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Andres Freund
On Fri, Jul 23, 2010 at 01:28:53PM -0400, Robert Haas wrote: On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing ha...@krosing.net wrote: On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote: On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing ha...@krosing.net wrote: On Thu, 2010-07-22 at 14:36

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Greg Smith
Joshua Tolley wrote: Relatively minor, but it would be convenient to avoid having to query $external_pooler to determine the client_addr of an incoming connection. You suggest this as a minor concern, but I consider it to be one of the most compelling arguments in favor of in-core pooling.

Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.

2010-07-23 Thread Andres Freund
On Sat, Jul 24, 2010 at 01:23:08AM -0400, Greg Smith wrote: Joshua Tolley wrote: Relatively minor, but it would be convenient to avoid having to query $external_pooler to determine the client_addr of an incoming connection. You suggest this as a minor concern, but I consider it to be one of

Re: [PERFORM] Strange explain on partitioned tables

2010-07-23 Thread Gerald Fontenay
Joshua D. Drake wrote: On Fri, 2010-07-23 at 15:03 -0700, Gerald Fontenay wrote: The PostgreSQL partitioning system is aimed to support perhaps a hundred inherited tables. You can expect to get poor performance on queries if you create 1000 of them. Hi, Why is that you would