On Fri, Jul 1, 2011 at 3:46 PM, Tom Lane wrote:
> Samuel Gendler writes:
> > I've got 2 nearly identical queries that perform incredibly differently.
>
> The reason the slow query sucks is that the planner is estimating at
> most one "s" row will match that complicated AND/OR condition, so it
>
Samuel Gendler writes:
> I've got 2 nearly identical queries that perform incredibly differently.
The reason the slow query sucks is that the planner is estimating at
most one "s" row will match that complicated AND/OR condition, so it
goes for a nestloop. In the "fast" query there is another co
On Jul 1, 2011, at 9:43 AM, Anthony Presley wrote:
> Was curious if there was some sort of Open Source version of Infinite Cache,
> and/or a memcache layer that can be "dropped" in front of PostgreSQL without
> application changes (which seems to be the "key" piece of Infinite Cache), or
> is th
On 07/01/2011 10:43 AM, Anthony Presley wrote:
Was curious if there was some sort of Open Source version of Infinite
Cache, and/or a memcache layer that can be "dropped" in front of
PostgreSQL without application changes (which seems to be the "key"
piece of Infinite Cache), or is this somethin
All:
Was curious if there was some sort of Open Source version of Infinite Cache,
and/or a memcache layer that can be "dropped" in front of PostgreSQL without
application changes (which seems to be the "key" piece of Infinite Cache),
or is this something that EnterpriseDB owns and you have to buy
I am now a bit puzzled after the initial satisfaction by Marinos' reply.
1. what do you mean exactly by "to ensure your UNION succeeds". The dblink
docs do not mention anything about issues using directly the suggested
dblink_send_query() + dblink_get_results(). What problems should I expect in
u
