From: | Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reducing statistics write overhead |
Date: | 2008-09-08 21:10:48 |
Message-ID: | 48C594D8.6050504@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Hmm. With the timestamp in the file, ISTM that we could put all the
> intelligence on the reader side. Reader checks file, sends message if
... snip ...
> remember the file timestamp it last wrote out. There are various ways
> you could design it but what comes to mind here is for readers to send
> a timestamp defined as minimum acceptable file timestamp (ie, their
> current clock time less whatever slop they want to allow). Then,
> when the collector gets a request with that timestamp <= its last
> write timestamp, it knows it need not do anything.
Attached is a patch that implements the described signalling. Additionally
following non-related changes have been made:
1. fopen/fclose replaced with AllocateFile/FreeFile
2. pgstat_report_stat() now also checks if there are functions to report
before returning. Previous behavior was to return immediately if no table
stats were available for reporting.
> responding to a new live write request. It's sort of annoying that
> the readers have to sleep for an arbitrary interval though. If we could
> get rid of that part...
>
It is, but I guess its unavoidable if we have to wait for the file to be
written. I'll try to do some load testing tomorrow, to see if something
nasty comes out.
regards,
Martin
Attachment | Content-Type | Size |
---|---|---|
stat-write.patch | text/x-diff | 13.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-09-08 21:40:39 | Re: Synchronous Log Shipping Replication |
Previous Message | Jeff Davis | 2008-09-08 20:25:18 | Re: Common Table Expressions (WITH RECURSIVE) patch |