On 2010-07-10 00:59, Greg Smith wrote:
Matthew Wakeling wrote:
> If you have an external pool solution, you can put it somewhere
> else - maybe on multiple somewhere elses.
This is the key point to observe: if you're at the point where you
have so many connections that you need a pool, the l
Sent from my iPhone
On Jul 9, 2010, at 18:25, Josh Berkus wrote:
So while adding (b) to core alone would be very useful for some users,
ironically it's generally for the more advanced users which are not
the
ones we're trying to help on this thread.
It would seem from evidence presente
On Fri, Jul 9, 2010 at 11:33 PM, Craig Ringer
wrote:
> On 10/07/2010 9:25 AM, Josh Berkus wrote:
>>
>>> It *is* the last place you want to put it, but putting it there can
>>> be much better than not putting it *anywhere*, which is what we've
>>> often seen.
>>
>> Well, what you proposed is an adm
On 10/07/2010 9:25 AM, Josh Berkus wrote:
It *is* the last place you want to put it, but putting it there can
be much better than not putting it *anywhere*, which is what we've
often seen.
Well, what you proposed is an admission control mechanism, which is
*different* from a connection pool,
> It *is* the last place you want to put it, but putting it there can
> be much better than not putting it *anywhere*, which is what we've
> often seen.
Well, what you proposed is an admission control mechanism, which is
*different* from a connection pool, although the two overlap. A
connection
On 10/07/10 00:56, Brad Nicholson wrote:
On Fri, 2010-07-09 at 00:42 -0400, Tom Lane wrote:
Perhaps not, but there's no obvious benefit either. Since there's
More Than One Way To Do It, it seems more practical to keep that as a
separate problem that can be solved by a choice of add-on pack
Greg Smith wrote:
> if you're at the point where you have so many connections that you
> need a pool, the last place you want to put that is on the
> overloaded database server itself. Therefore, it must be an
> external piece of software to be effective, rather than being part
> of the server
Hi Tom,
Thanks for the help - much appreciated.
Yes I'm using PostGIS, and with a simply join to a relating table I could get
access to the geometry for these point positions. Is using the GIST r-tree
index faster than using the 2 b-tree indexes on the lat and long values? I
guess this is a qu
Richard Yen wrote:
I figured that pg_xlog and data/base could both be on the FusionIO drive, since
there would be no latency when there are no spindles.
(Rolls eyes) Please be careful about how much SSD Kool-Aid you drink,
and be skeptical of vendor claims. They don't just make latency go
Jeremy Palmer writes:
> This is the query that does not use the indexes:
> SELECT
> coo.nod_id,
> 640*radians(sqrt((coo.value1 - -41.0618)^2+((coo.value2 -
> 175.58461)*cos(radians(-41.0618)))^2)) as distance
> FROM
> crs_coordinate coo
> WHERE
> coo.value1 between -41.0618-degrees(
Matthew Wakeling wrote:
If you have an external pool solution, you can put it somewhere else -
maybe on multiple somewhere elses.
This is the key point to observe: if you're at the point where you have
so many connections that you need a pool, the last place you want to put
that is on the ov
I'm having trouble getting the query planner to use indexes. The situation
occurs when writing a query that uses functions for defining the parameters for
the conditions on the indexed columns. The system I'm running is Windows Server
2003, using version 8.4.2 of PostgreSQL.
This is the followi
On Fri, Jul 9, 2010 at 12:42 AM, Tom Lane wrote:
> Samuel Gendler writes:
>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
>> wrote:
>>> If you're not using a connection pool, start using one.
>
>> I see this issue and subsequent advice cross this list awfully
>> frequently. Is there in architec
On Fri, Jul 9, 2010 at 6:13 AM, damien hostin wrote:
>> Have you tried running ANALYZE on the production server?
>>
>> You might also want to try ALTER TABLE ... SET STATISTICS to a large
>> value on some of the join columns involved in the query.
>
> Hello,
>
> Before comparing the test case on t
"Jorge Montero" wrote:
> If anything was built in the database to handle such connections,
> I'd recommend a big, bold warning, recommending the use of client-
> side pooling if available.
+1
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make chang
If anything was built in the database to handle such connections, I'd recommend
a big, bold warning, recommending the use of client-side pooling if available.
For something like, say, a web-server, pooling connections to the database
provides a massive performance advantage regardless of how goo
Matthew Wakeling wrote:
> On Fri, 9 Jul 2010, Kevin Grittner wrote:
>>> Interesting idea. As far as I can see, you are suggesting
>>> solving the too many connections problem by allowing lots of
>>> connections, but only allowing a certain number to do anything
>>> at a time?
>>
>> Right.
>
> I t
On Fri, 9 Jul 2010, Kevin Grittner wrote:
Interesting idea. As far as I can see, you are suggesting solving
the too many connections problem by allowing lots of connections,
but only allowing a certain number to do anything at a time?
Right.
I think in some situations, this arrangement would
If your app is running under Tomcat, connection pooling is extremely easy to
set up from there: It has connection pooling mechanisms built in. Request your
db connections using said mechanisms, instead of doing it manually, make a
couple of changes to server.xml, and the problem goes away. Hundr
In case there's any doubt, the questions below aren't rhetorical.
Matthew Wakeling wrote:
> Interesting idea. As far as I can see, you are suggesting solving
> the too many connections problem by allowing lots of connections,
> but only allowing a certain number to do anything at a time?
Rig
On Fri, 9 Jul 2010, Kevin Grittner wrote:
Any thoughts on the "minimalist" solution I suggested a couple weeks
ago?:
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01385.php
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01387.php
So far, there has been no comment by anyone...
Brad Nicholson wrote:
> Just like replication, pooling has different approaches. I do
> think that in both cases, having a solution that works, easily,
> out of the "box" will meet the needs of most users.
Any thoughts on the "minimalist" solution I suggested a couple weeks
ago?:
http://arc
Thanx you all for the replies.
I got a gist on where should I head towards
like I should rely a bit on postgres for performance and rest on my
tomcat and application.
And will try connection pooling on postgres part.
And if I come back for any query (related to this topic) then this
time it will b
On Fri, 2010-07-09 at 00:42 -0400, Tom Lane wrote:
> Samuel Gendler writes:
> > On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
> > wrote:
> >> If you're not using a connection pool, start using one.
>
> > I see this issue and subsequent advice cross this list awfully
> > frequently. Is there in a
Robert Haas a écrit :
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin wrote:
Hello again,
At last, I check the same query with the same data on my desktop computer.
Just after loading the data, the queries were slow, I launch a vaccum
analyse which collect good stats on the main table, the q
Otherwise I'm wondering if PostgreSQL will begin really suffering in
performance on workloads where queries are big and expensive but there
are relatively few of them running at a time.
Oh, I should note at this point that I'm *not* whining that "someone"
should volunteer to do this, or that "t
On Fri, Jul 9, 2010 at 2:08 AM, Russell Smith wrote:
> On 09/07/10 02:31, Ryan Wexler wrote:
>
>
> The only other difference between the boxes is the postgresql version. The
> new one has 8.4-2 from the yum install instructions on the site:
> http://yum.pgrpms.org/reporpms/repoview/pgdg-centos.ht
Thanx you all for the replies.
I got a gist on where should I head towards
like I should rely a bit on postgres for performance and rest on my
tomcat and application.
And will try connection pooling on postgres part.
And if I come back for any query (related to this topic) then this
time it will b
On 09/07/10 02:31, Ryan Wexler wrote:
> Thanks a lot for all the comments. The fact that both my windows box
> and the old linux box both show a massive performance improvement over
> the new linux box seems to point to hardware to me. I am not sure how
> to test the fsync issue, but i don't see
On 09/07/10 12:42, Tom Lane wrote:
> Samuel Gendler writes:
>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
>> wrote:
>>> If you're not using a connection pool, start using one.
>
>> I see this issue and subsequent advice cross this list awfully
>> frequently. Is there in architectural reason w
30 matches
Mail list logo
