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
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
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 something
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 this
Samuel Gendler sgend...@ideasculptor.com 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
On Fri, Jul 1, 2011 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Samuel Gendler sgend...@ideasculptor.com 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
