On Sat, Sep 26, 2015 at 3:08 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> memcpy() can cope with unaligned data; structure member assignment can't.
>
> So doesn't coping means, it anyways have to have to pay the performance
> penality to make it equivalent to aligned address access. Apart from that,
> today I had read about memcpy's behaviour incase of unaligned address,
> it seems from some of the information on net that it could be unsafe
> [1],[2].
I'm not concerned about the performance penalty for unaligned access
in this case; I'm concerned about the fact that on some platforms it
causes a segmentation fault. The links you've provided there are
examples of cases where that wasn't true, and people reported that as
a bug in memcpy.
> Yes, you have figured out correctly, I was under impression that we
> will have single node execution in worker for first version and then
> will extend it later.
No, I really want it to work with multiple nodes from the start, and
I've pretty much got that working here now.
> QueryDesc's totaltime is for instrumentation information for plugin's
> like pg_stat_statements and we need only the total buffer usage
> of each worker to make it work as the other information is already
> collected in master backend, so I think that should work as I have
> written.
I don't think that's right at all. First, an extension can choose to
look at any part of the Instrumentation, not just the buffer usage.
Secondly, the buffer usage inside QueryDesc's totaltime isn't the same
as the global pgBufferUsage.
>> Assuming I'm not confused, I'm planning to see about fixing this...
>
> Can't we just traverse the queryDesc->planstate tree and fetch/add
> all the instrument information if there are multiple nodes?
Well you need to add each node's information in each worker to the
corresponding node in the leader. You're not just adding them all up.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
