| From: | Joel Jacobson <joel(at)trustly(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: pg_stat_*_columns? |
| Date: | 2015-06-20 14:12:05 |
| Message-ID: | CAASwCXdj+-rC_w+XJU2BcCRyx86iNdWYpp=_fNnkS7EQjriTCA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 16, 2015 at 4:47 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> Magnus idea was to first optimize the collector to make it less of a
>> problem to collect more data. Sounds like a good thing to do, but maybe
>> more data in it wouldn't be a problem as long as you don't read too
>> often from it?
>>
>
> The stats collector is a known problem under certain circumstances, so
> improving it would probably be a good thing. The first thing that comes to
> mind is splitting it into more files.
>
>
Is there any chance the project would accept a patch which adds the
pg_stat_*_columns-feature without first optimizing the collector? I guess
it primarily depends on how much of the new code that would need to be
rewritten, if the collector is optimized/rewritten in the future?
(I would be interested in sponsoring the work, if anyone is interested.)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-06-20 14:17:22 | Re: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H |
| Previous Message | Robert Haas | 2015-06-20 13:35:39 | Re: castoroides spinlock failure on test_shm_mq |