<p>What I'm doing is fairly simple:</p>

<pre><code>{% cache %}
    {% set jobs = craft.entries.section('job').find({ order: 'dateCreated asc', limit: 0 }) %}
    {% for job in jobs %}
        {{ macros.jobProfile(job) }}
    {% endfor %}
{% endcache %}
</code></pre>

<p>... where the macro simply renders a block with a couple of things in it. I need to display all 200 entries I have, but Craft usually times out on that query (128MB RAM set).</p>

<p>Is there a way to tell Craft to not fetch all fields of that query, so I can optimize it directly at that point? I believe I have some content blocks in there, which probably go into RAM and eat it up, but are not needed at that time.</p>

<p>Any other recommendations are highly welcome. (I don't wanna write a plugin, or paginate at this point.)</p>

<p><strong>Update:</strong></p>

<pre><code>{% macro jobProfile(job) %}

    {% import _self as macros %}

    &lt;div&gt;
        {% cache %}
            {% set attributes = job.jobProfileAttributes %}
            {% set attributeStr = "" %}
            {% set counter = 0 %}
            {% for attr in attributes %}
                {% if counter == 0 %}
                    {% set attributeStr = attr.slug%}
                {% else %}
                    {% set attributeStr = attributeStr ~" " ~attr.slug%}
                {% endif %}

                {% set counter = counter + 1 %}
            {% endfor %}

            &lt;div style="background-image: url({{ macros.renderImageUrl(job.jobProfileImage, 'teaser1') }})"
                data-jobProfileAttributes="{{ attributeStr }}"&gt;
                &lt;a class="teaserLink" href="{{ url(job.uri) }}"&gt;
                    &lt;h4&gt;{{ job.jobProfileDesignation|raw }}&lt;/h4&gt;
                &lt;/a&gt;
            &lt;/div&gt;

        {% endcache %}

    &lt;/div&gt;

{% endmacro %}
</code></pre>

CC BY-SA 3.0
2015-07-13T06:32:52.147Z
What makes you think it's the selected fields that is eating the memory?  If you know you only need 200, try setting the limit to 200?  Can you post the macro?  It might be doing something memory intensive as well.
Brad Bell
CC BY-SA 3.0
2015-07-13T11:05:35.777Z
Yeah you shouldn't run out of RAM fetching 200 entries. Try `{% set jobs = craft.entries.section('job').order('dateCreated asc').limit(200) %}`
darylknight
CC BY-SA 3.0
2015-07-13T13:44:20.220Z
but uhm....when i only have arround 200 entries..limit 200....wont do much difference then what i have now...im rendering all out...which is....200 :)
nexflo
CC BY-SA 3.0
2015-07-13T14:09:34.707Z
Could it be the cache wrapping the 200 other caches? And I'm not seeing the use for two for loops for jobs? You can remove the outer one at least? The one in the template, not the macro?
megatrond
CC BY-SA 3.0
2015-07-13T17:42:06.370Z
Like @megatrond I'm confused by what you are passing to `jobProfile`. A single `job`? Or multiple `jobs`?
Marion Newlevant
CC BY-SA 3.0
2015-07-14T18:19:55.630Z
was an error in stack exchange..obviously theres only 1 loop in there....well my question is simple: it seems my query takes a super long time to process...i know that there are quite a few fields inside that object....hence that all goes into memory....thought that could trigger the memory timeout....thats why i wanted to limit the footprint.
nexflo
<cache><queries>
Limit fields in query / Optimize query
# Limit fields in query / Optimize query

(Asked by: username_0 on 2015-07-13)

What I'm doing is fairly simple:
{% cache %}
    {% set jobs = craft.entries.section('job').find({ order: 'dateCreated asc', limit: 0 }) %}
    {% for job in jobs %}
        {{ macros.jobProfile(job) }}
    {% endfor %}
{% endcache %}

... where the macro simply renders a block with a couple of things in it. I need to display all 200 entries I have, but Craft usually times out on that query (128MB RAM set).
Is there a way to tell Craft to not fetch all fields of that query, so I can optimize it directly at that point? I believe I have some content blocks in there, which probably go into RAM and eat it up, but are not needed at that time.
Any other recommendations are highly welcome. (I don't wanna write a plugin, or paginate at this point.)
Update:
{% macro jobProfile(job) %}

    {% import _self as macros %}

    
        {% cache %}
            {% set attributes = job.jobProfileAttributes %}
            {% set attributeStr = "" %}
            {% set counter = 0 %}
            {% for attr in attributes %}
                {% if counter == 0 %}
                    {% set attributeStr = attr.slug%}
                {% else %}
                    {% set attributeStr = attributeStr ~" " ~attr.slug%}
                {% endif %}

                {% set counter = counter + 1 %}
            {% endfor %}

            
                
                    {{ job.jobProfileDesignation|raw }}
                
            

        {% endcache %}

    

{% endmacro %}

**Tags:** cache, queries

> **Comments:**
> **username_1**: What makes you think it's the selected fields that is eating the memory?  If you know you only need 200, try setting the limit to 200?  Can you post the macro?  It might be doing something memory intensive as well.  
> **username_2**: Yeah you shouldn't run out of RAM fetching 200 entries. Try `{% set jobs = craft.entries.section('job').order('dateCreated asc').limit(200) %}`  
> **username_0**: but uhm....when i only have arround 200 entries..limit 200....wont do much difference then what i have now...im rendering all out...which is....200 :)  
> **username_3**: Could it be the cache wrapping the 200 other caches? And I'm not seeing the use for two for loops for jobs? You can remove the outer one at least? The one in the template, not the macro?  
> **username_4**: Like @username_3 I'm confused by what you are passing to `jobProfile`. A single `job`? Or multiple `jobs`?  
> **username_0**: was an error in stack exchange..obviously theres only 1 loop in there....well my question is simple: it seems my query takes a super long time to process...i know that there are quite a few fields inside that object....hence that all goes into memory....thought that could trigger the memory timeout....thats why i wanted to limit the footprint.  

---

## 0 answers

