From: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | S Arvind <arvindwill(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Running some query in low priority |
Date: | 2009-11-05 13:42:56 |
Message-ID: | 2f4958ff0911050542m479791c6lb0772f23a474cd37@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2009/11/5 Matthew Wakeling <matthew(at)flymine(dot)org>
> On Thu, 5 Nov 2009, Grzegorz Jaśkiewicz wrote:
>
>> If it is an insert of some sort, than divide it up. If it is a query that
>> runs over data,
>> use limits, and do it in small batches. Overall, divide in conquer
>> approach works in
>> these scenarios.
>>
>
> Unfortunately, dividing the work up can cause a much greater load, which
> would make things worse. If you are inserting in smaller chunks and
> committing more frequently that can reduce performance. If you split up
> queries with limit and offset, that will just multiply the number of times
> the query has to be run. Each time, the query will be evaluated, the first
> <offset> rows thrown away, and the next <limit> rows returned, which will
> waste a huge amount of time.
>
> If you are inserting data, then use a COPY from stdin, and then you can
> throttle the data stream. When you are querying, declare a cursor, and fetch
> from it at a throttled rate.
>
as with everything, you have to find the right balance. I think he is
looking for low impact, not speed. So he has to trade one for another. Find
a small enough batch size, but not too small, cos like you said - things
will have too much impact otherwise.
--
GJ
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-11-05 14:28:15 | Re: Followup: vacuum'ing toast |
Previous Message | Matthew Wakeling | 2009-11-05 13:39:35 | Re: Running some query in low priority |