Hi Tom
You wrote:
> Path alternatives are rejected
> whenever possible before moving up to the next join level, so that what
> we have rejected is actually just a plan fragment in most cases.
Thanks for the quick answer. This sounds like a fair implementation decision.
Background for asking this
On Fri, Mar 21, 2014 at 1:07 PM, Stefan Keller wrote:
> Hi Tom
>
> You wrote:
> > Path alternatives are rejected
> > whenever possible before moving up to the next join level, so that what
> > we have rejected is actually just a plan fragment in most cases.
>
> Thanks for the quick answer. This s
On 21-03-14 00:56, Stefan Amshey wrote:
We have a slow performing query that we are trying to improve, and it
appears to be performing a sequential scan at a point where it should
be utilizing an index. Can anyone tell me why postgres is opting to do
it this way?
The original query is as foll
There have been many discussions about adding hints to Postgres over the
years. All have been firmly rejected by the Postgres developers, with
well-argued reasons. Search the archives to learn more about this topic.
On the other hand, Postgres does have hints. They're just called settings.
You c
Craig James writes:
> There have been many discussions about adding hints to Postgres over the
> years. All have been firmly rejected by the Postgres developers, with
> well-argued reasons. Search the archives to learn more about this topic.
To clarify: there are good reasons not to like what Or
Hi all,
Brett Wooldridge, the creator of HikariCP [1] - a high performance
Java connection pool - is contemplating the idea to change the way
pooling is done in HikariCP and have a fixed-size pool of connections
always open.
No maxPoolSize, no minIdle, no minPoolSize, juste a poolSize parameter
w
Guillaume Smet wrote
> Brett Wooldridge, the creator of HikariCP [1] - a high performance
> Java connection pool - is contemplating the idea to change the way
> pooling is done in HikariCP and have a fixed-size pool of connections
> always open.
>
> No maxPoolSize, no minIdle, no minPoolSize, just
On Fri, Mar 21, 2014 at 4:49 PM, David Johnston wrote:
> Consider this train-of-thought: no matter how large the pool size if you
> are constantly keeping, say, 90% of the connections actively working then
> having, on average, 10% of the connections sitting idle is probably not
> going to be not
Guillaume Smet writes:
> On Fri, Mar 21, 2014 at 4:49 PM, David Johnston wrote:
>> Consider this train-of-thought: no matter how large the pool size if you
>> are constantly keeping, say, 90% of the connections actively working then
>> having, on average, 10% of the connections sitting idle is p
Reaching the maxPoolSize from the minPoolSize means creating the
connections at the crucial moment where the client application is in the
desperate need of completing an important query/transaction which the
primary responsibility since it cannot hold the data collected.
So here the connection cre
Hi Tom,
On Fri, Mar 21, 2014 at 5:17 PM, Tom Lane wrote:
> It will cost you, in ProcArray scans for example. But lots-of-idle-
> connections is exactly what a pooler is supposed to prevent. If you have
> a server that can handle say 10 active queries, you should have a pool
> size of 10, not 10
Hi Sethu,
On Fri, Mar 21, 2014 at 6:51 PM, Sethu Prasad wrote:
> So here the connection creation action is the costliest among all the other
> management tasks. so keeping the connections ready is the best option.
That's why you often have a minIdle parameter which allows to create
idle connecti
Sethu Prasad wrote
> Reaching the maxPoolSize from the minPoolSize means creating the
> connections at the crucial moment where the client application is in the
> desperate need of completing an important query/transaction which the
> primary responsibility since it cannot hold the data collected.
On Fri, Mar 21, 2014 at 3:36 PM, Guillaume Smet
wrote:
> On Fri, Mar 21, 2014 at 5:17 PM, Tom Lane wrote:
>> It will cost you, in ProcArray scans for example. But lots-of-idle-
>> connections is exactly what a pooler is supposed to prevent. If you have
>> a server that can handle say 10 active
On 03/21/2014 08:34 AM, Craig James wrote:
There have been many discussions about adding hints to Postgres over the
years. All have been firmly rejected by the Postgres developers, with
well-argued reasons. Search the archives to learn more about this topic.
While that's true, and I agree wit
Hi there,
I've got a relatively simple query that contains expensive BCRYPT
functions that gets optimized in a way that causes postgres to compute
more bcrypt hashes than necessary, thereby dramatically slowing things
down.
In a certain part of our application we need to lookup users by their
use
16 matches
Mail list logo
