23 February 2017 at 17:35, Pavel Stehule wrote:
>
>
> 2017-02-23 15:02 GMT+01:00 Rowan Seymour :
>
>> Hi Pavel. That suggestion gets me as far as LIMIT 694 with the fast plan
>> then things get slow again. This is now what happens at LIMIT 695:
>>
>> Limit (co
e contact_id column but without it the planner
picks a slow approach for even smaller LIMIT values.
On 23 February 2017 at 15:32, Pavel Stehule wrote:
>
>
> 2017-02-23 14:11 GMT+01:00 Rowan Seymour :
>
>> Hi guys
>>
>> I'm a bit stuck on a query that perfor
cts_contactgroup_contacts_contactgroup_id_0f909f73_uniq on
contacts_contactgroup_contacts (cost=0.43..18967.29 rows=497992 width=4)
(actual time=0.073..0.273 rows=550 loops=1)
Index Cond: (contactgroup_id = 1)
Heap Fetches: 0
Buffers: shared read=6
Total runtim
w timeouts. I'm wondering now if
activity on the other database in this instance doesn't occasionally push
our indexes out of memory.
Thanks, Rowan
On 10 June 2016 at 18:11, Alex Ignatov wrote:
>
> On 10.06.2016 16:04, Rowan Seymour wrote:
>
> In our Django app we have message
bels table but I couldn't
find a way of avoiding the in-memory sort.
- Have thought about dynamically creating partial indexes for each label
using an array column on msgs_message to hold label ids, and index
condition like WHERE label_ids && ARRAY[123] but not sure what other
problems I'll run into with hundreds of indexes on the same table.
Server is an Amazon RDS instance with default settings and Postgres 9.3.10,
with one other database in the instance.
All advice very much appreciated, thanks
--
*Rowan Seymour* | +260 964153686
