Thanks for your comments.
On 8.11.2013 15:31, Tom Lane wrote:
AFAICT, the reason the second plan is slow is the large number of
checks of the IN list. The planner does account for the cost of that,
but it's drastically underestimating that cost relative to the cost of
I/O for the heap and inde
Hi,
I would like to know, how does the size of the IN list affect query planner.
I have a query
select distinct on (event_id, tag_id) et.id,
e.id as event_id, t.id as tag_id, t.name,
t.user_id, t.shared, t.color,
case
when ea.id <> e.id then true
else false
On 5.11.2013 23:19, Merlin Moncure wrote:
On Tue, Nov 5, 2013 at 3:52 PM, Jan Walter wrote:
On 5.11.2013 20:51, Merlin Moncure wrote:
On Tue, Nov 5, 2013 at 11:30 AM, Merlin Moncure wrote:
On Tue, Nov 5, 2013 at 6:25 AM, Jan Walter wrote:
Hi,
I am in a need of a very robust (esp. fast in
On 5.11.2013 20:51, Merlin Moncure wrote:
On Tue, Nov 5, 2013 at 11:30 AM, Merlin Moncure wrote:
On Tue, Nov 5, 2013 at 6:25 AM, Jan Walter wrote:
Hi,
I am in a need of a very robust (esp. fast in read, non-blocking in update)
tree structure storage (95% trees are of depth <4, current
Hi,
I am in a need of a very robust (esp. fast in read, non-blocking in
update) tree structure storage (95% trees are of depth <4, current max.
is 12). We have 10k-100k trees now, millions in the future.
I made many tests, benchmarks of usual operations, and after all,
materialized path ('1.5.
