On 2011-11-20 15:00, Jon Nelson wrote:
Do you happen to recall if disk I/O is
counted as user or system time?
Neither, traditionally. Those times are cpu times;
they only account for what the cpu was doing.
The disks could be working in parallel as a result
of cpu actions, and probably were -
On Sun, Nov 20, 2011 at 7:56 AM, Jeremy Harris wrote:
> On 2011-11-17 17:10, Jon Nelson wrote:
>>
>> external sort ended, 7708696 disk blocks used: CPU 359.84s/57504.66u
>> sec elapsed 58966.76 sec
>>
>> Am I to understand that the CPU portion of the sorting only took 6
>> minutes but the sort its
On 2011-11-17 17:10, Jon Nelson wrote:
external sort ended, 7708696 disk blocks used: CPU 359.84s/57504.66u
sec elapsed 58966.76 sec
Am I to understand that the CPU portion of the sorting only took 6
minutes but the sort itself took almost 16.5 hours and used approx
60GB of disk space?
I real
> The first log statement is expected. The second log statement, however, isn't.
> The total table size is (as noted earlier) about 5GB and, in fact, fit
> into one nice hash table (approx 15GB in size).
> Is the sorting that is necessary for index creation unable to use a
> hash table? (This is a
Jon Nelson writes:
> Is the sorting that is necessary for index creation unable to use a
> hash table? (This is a standard btree index).
Hash aggregation isn't sorting --- it's only useful for grouping.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql
A follow-up question.
Even with both work_mem and maintenance_work_mem equal to 16GB, I see this:
LOG: 0: begin index sort: unique = f, workMem = 16777216, randomAccess = f
and shortly thereafter:
LOG: 0: switching to external sort with 59919 tapes: CPU
2.59s/13.20u sec elapsed 16.85 sec
I'll try to compile multiple questions/answers into a single response.
On Thu, Nov 17, 2011 at 11:16 AM, Claudio Freire wrote:
> On Thu, Nov 17, 2011 at 2:10 PM, Jon Nelson wrote:
>> What sorts of things should I be looking at to improve the performance
>> of this query? Is my interpretation of
Jon Nelson writes:
> This is on PG 8.4.8 on Linux, 16GB of "real" RAM.
> Most recently, I enabled trace_sort, disabled hash aggregation[1], and
> set a large work_mem (normally very small, in this case I tried
> anything from 8MB to 256MB. I even tried 1GB and 2GB).
FWIW, I think hash aggregation
On 11/17/11 9:10 AM, Jon Nelson wrote:
I have one query which does not run very often. Sometimes it may be
months between runs.
However, when it does get executed, it scans approximately 100
identically-structured tables (a form of partitioning), extracts and
groups on a subset of the columns, an
On Thu, Nov 17, 2011 at 2:10 PM, Jon Nelson wrote:
> What sorts of things should I be looking at to improve the performance
> of this query? Is my interpretation of that log line totally off base?
You'll have to post some more details.
Like a query and an explain/explain analyze.
Memory consumpt
I have one query which does not run very often. Sometimes it may be
months between runs.
However, when it does get executed, it scans approximately 100
identically-structured tables (a form of partitioning), extracts and
groups on a subset of the columns, and creates a new table. The
individual tab
11 matches
Mail list logo
