On 24/07/10 13:23, 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 the
> most
On 24/07/10 01:28, Robert Haas wrote:
> Well, if we could change the backends so that they could fully
> reinitialize themselves (disconnect from a database to which they are
> bound, etc.), I don't see why we couldn't use the Apache approach.
This would offer the bonus on the side that it'd be m
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 expec
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 on
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.
On Fri, Jul 23, 2010 at 01:28:53PM -0400, Robert Haas wrote:
> On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing wrote:
> > On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
> >> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
> >> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
>
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 execu
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 performa
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
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).
On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> >> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> >> wrote:
> >> > So rather than asking "should core have a connection pool"
On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing wrote:
> On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
>> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
>> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
>> >> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
>> >> wrote:
>> >
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
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
> > wrote:
> >> So rather than asking "should core have a connection pool" perhaps
> >> what's needed is to ask "what can an in-core poo
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 a
Hello
2010/7/23 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.
> Tak
16 matches
Mail list logo
