From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoid memory leaks during ANALYZE's compute_index_stats() ? |
Date: | 2010-11-09 04:03:06 |
Message-ID: | 9003.1289275386@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> On 11/8/10 5:04 PM, Tom Lane wrote:
>> The extra copying is a bit annoying, since
>> it would add cycles while accomplishing nothing useful for index
>> expressions with no intermediate results, but I'm thinking this is a
>> must-fix.
> I'd say that performance numbers is what to check on this. How much
> does it affect low-memory expressions to do the copying?
It's noticeable but not horrible. I tried this test case:
regression=# \d tst
Table "public.tst"
Column | Type | Modifiers
--------+------------------+-----------
f1 | double precision |
Indexes:
"tsti" btree ((f1 + 1.0::double precision))
with 100000 rows on a 32-bit machine (so that float8 is pass-by-ref).
The ANALYZE time went from about 625 msec to about 685. I believe that
this is pretty much the worst case percentage-wise: the table is small
enough to fit in RAM, so no I/O is involved, and the index expression is
about as simple and cheap to evaluate as it could possibly be, and the
amount of work done analyzing the main table is about as small as it
could possibly be. In any other situation those other components of
the ANALYZE cost would grow proportionally more than the copying cost.
Not-too-well-tested-yet patch attached.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
analyze-leak.patch | text/x-patch | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2010-11-09 05:45:12 | Re: Should we use make -k on the buildfarm? |
Previous Message | Jeff Davis | 2010-11-09 03:44:45 | CLUSTER can change t_len |