Greg Matthews writes:
> Looks good to me. I built PG with this change, no kernel warnings after
> ~10 minutes of running. I'll continue to monitor but I think this fixes
> the syndrome. Thanks Tom.
Patch committed -- thanks for checking it.
regards, tom lane
--
Sent v
On Fri, Nov 18, 2011 at 2:55 AM, CSS wrote:
> ps - considering the new PostgreSQL Performance book that Packt has, any
> strong feelings about that one way or the other? Does it go very far beyond
> what's on the wiki?
Since others have provided perfectly good answers to all your other
questi
On Fri, Nov 18, 2011 at 3:39 PM, Greg Smith wrote:
> On 11/17/2011 10:44 PM, CSS wrote:
>
>> Is there any sort of simple documentation on the query planner that might
>> cover how things like increased RAM could impact how a query is executed?
>>
>
> There is no *simple* documentation on any part
On 18 Listopad 2011, 17:17, Scott Marlowe wrote:
> On Fri, Nov 18, 2011 at 3:09 AM, Greg Smith wrote:
>> On 11/17/2011 10:44 PM, CSS wrote:
>>>
>>> Is there any sort of simple documentation on the query planner that
>>> might
>>> cover how things like increased RAM could impact how a query is
>>>
On Fri, Nov 18, 2011 at 3:09 AM, Greg Smith wrote:
> On 11/17/2011 10:44 PM, CSS wrote:
>>
>> Is there any sort of simple documentation on the query planner that might
>> cover how things like increased RAM could impact how a query is executed?
>
> There is no *simple* documentation on any part of
Claudio Freire writes:
> On Thu, Nov 17, 2011 at 10:07 PM, Greg Matthews
> wrote:
>>if (smoothed_alloc <= (float) recent_alloc)
>>smoothed_alloc = recent_alloc;
>>else if (smoothed_alloc >= 0.1)
>>smoothed_alloc += ((float) recent_alloc - smooth
On Thu, Nov 17, 2011 at 10:07 PM, Greg Matthews
wrote:
> if (smoothed_alloc <= (float) recent_alloc)
> smoothed_alloc = recent_alloc;
> else if (smoothed_alloc >= 0.1)
> smoothed_alloc += ((float) recent_alloc - smoothed_alloc) /
>
can you run an analyze command first and then post here the results of:
select * FROM pg_stats WHERE tablename = 'delayed_jobs';
?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/index-usage-for-min-vs-order-by-asc-limit-1-tp5002928p5004410.html
Sent from the PostgreSQL
2011/11/18 Tomas Vondra :
> On 18 Listopad 2011, 10:55, CSS wrote:
>> Hello,
>>
>> I'm going to be testing some new hardware (see
>> http://archives.postgresql.org/pgsql-performance/2011-11/msg00230.php) and
>> while I've done some very rudimentary before/after tests with pgbench, I'm
>> looking to
On 18 Listopad 2011, 10:55, CSS wrote:
> Hello,
>
> I'm going to be testing some new hardware (see
> http://archives.postgresql.org/pgsql-performance/2011-11/msg00230.php) and
> while I've done some very rudimentary before/after tests with pgbench, I'm
> looking to pull more info than I have in the
On 11/17/2011 10:44 PM, CSS wrote:
Is there any sort of simple documentation on the query planner that
might cover how things like increased RAM could impact how a query is
executed?
There is no *simple* documentation on any part of the query planner
that's also accurate. Query planning is i
Hello,
I'm going to be testing some new hardware (see
http://archives.postgresql.org/pgsql-performance/2011-11/msg00230.php) and
while I've done some very rudimentary before/after tests with pgbench, I'm
looking to pull more info than I have in the past, and I'd really like to
automate things
12 matches
Mail list logo
