Hello Maks,
As I think Sam suspects the issue might be that you may not have enough
RAM, or not enough RAM is allocated to shared_buffers, or you may have this
table's data being evicted from shared_buffers because of some other
queries, so while you are identifying all the rows in your fast
I have a database, table users, with column profile_id, and the
following query:
EXPLAIN ANALYZE SELECT * FROM users_user WHERE profile_id IN (...50 ids...);
Result:
Index Scan using users_user_83a0eb3f on users_user (cost=0.50..292.22
rows=50
width=633) (actual time=0.039..0.622 rows=44
On 05/16/2015 10:44 PM, Maks Materkov wrote:
I have a database, table users, with column profile_id, and the
following query:
EXPLAIN ANALYZE SELECT * FROM users_user WHERE profile_id IN (...50 ids...);
Result:
Index Scan using users_user_83a0eb3f on users_user (cost=0.50..292.22
rows=50
Hi,
I am reading the docu and am looking for an example our explanation as to the
difference of setof and arrays.
But maybe this is not even relevant. The reason I am looking for this is
because I need to build a function that looks for all records whose ids are in
a pool of other records.
On Sep 26, 2012, at 16:28, Alexander Reichstadt l...@mac.com wrote:
Hi,
I am reading the docu and am looking for an example our explanation as to the
difference of setof and arrays.
But maybe this is not even relevant. The reason I am looking for this is
because I need to build a
Heureka, it works.
Thanks!
Am 26.09.2012 um 22:37 schrieb David Johnston:
On Sep 26, 2012, at 16:28, Alexander Reichstadt l...@mac.com wrote:
Hi,
I am reading the docu and am looking for an example our explanation as to
the difference of setof and arrays.
But maybe this is not even
Playing with postgresql I have seen that sometime a very long IN (list
of ids) can rise a max_recursion_error (or something like that).
An easy workaround when the list is computer generated and EXISTS is
infeasible (too slow), is breaking the list in log(n) OR parts.
Like in this python
