On Jan 11, 2009, at 9:43 PM, M. Edward (Ed) Borasky wrote:
Luke Lonergan wrote:
Not to mention the #1 cause of server faults in my experience: OS
kernel bug causes a crash. Battery backup doesn't help you much
there.
Not that long ago (a month or so) we ran into a problem where hpacucl
>>> "Mark Wong" wrote:
> It appears to peak around 220 database connections:
>
> http://pugs.postgresql.org/node/514
Interesting. What did you use for connection pooling?
My tests have never stayed that flat as the connections in use
climbed. I'm curious why we're seeing such different r
On Monday 12 January 2009, Bill Preston
wrote:
> As to the second example with the delete. There are no foreign keys.
> For the index. If the table has fields a,b,c and d.
> We have a btree index (a,b,c,d)
> and we are saying DELETE FROM table_messed_up WHERE a=x.
>
Is there anything special abo
So, I had a query that uses a postgis geometry index and the planner was
underestimating the number of rows it would return. Because of this,
the planner was choosing the geometry index over a compound index on the
other columns in the WHERE clause. So, I thought, let me increase the
stats target
Jeff Frost writes:
> So, my question is, should changing the stats target on the shape column
> affect the stats for the content_id and content_type columns?
It would change the size of the sample for the table, which might
improve the accuracy of the stats. IIRC you'd still get the same number
On Tue, 13 Jan 2009, Tom Lane wrote:
Jeff Frost writes:
So, my question is, should changing the stats target on the shape column
affect the stats for the content_id and content_type columns?
It would change the size of the sample for the table, which might
improve the accuracy of the stats.
Jeff Frost writes:
> On Tue, 13 Jan 2009, Tom Lane wrote:
>> It would change the size of the sample for the table, which might
>> improve the accuracy of the stats. IIRC you'd still get the same number
>> of histogram entries and most-common-values for the other columns, but
>> they might be more
On Tue, 13 Jan 2009, Tom Lane wrote:
Jeff Frost writes:
On Tue, 13 Jan 2009, Tom Lane wrote:
It would change the size of the sample for the table, which might
improve the accuracy of the stats. IIRC you'd still get the same number
of histogram entries and most-common-values for the other col
On Tue, Jan 13, 2009 at 7:40 AM, Kevin Grittner
wrote:
"Mark Wong" wrote:
>
>> It appears to peak around 220 database connections:
>>
>> http://pugs.postgresql.org/node/514
>
> Interesting. What did you use for connection pooling?
It's a fairly dumb but custom built C program for the test
We are currently storing a large amount of networking data. The
database size is over 50 Gigabytes. It also grows by 10 Gigabytes
every month.
We are looking if there is a way to speedup lookups by IP Address.
The primary key is a set of values. And the key does include IP
Address as well. Will i
On Wed, Jan 14, 2009 at 12:53 AM, Maksim Sosnovskiy wrote:
Will it be more efficient to also add index on IP
> Address to speedup lookups by IP?
Most likely, especially if the IP address is not the first column in
your primary key index.
Have you done an explain analyze of your ip lookup query?
11 matches
Mail list logo
