On Sat, Dec 17, 2011 at 1:00 AM, Jim Nasby wrote:
> I also wonder how much this throws some previous performance tests into
> suspicion. If it's not uncommon for performance improvement attempts to shift
> a bottleneck to a different part of the system and marginally hurt
> performance then we
On Dec 16, 2011, at 7:25 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On that theory, I'm inclined to think that's not really a problem.
>> We'll go nuts if we refuse to commit anything until it shows a
>> meaningful win on every imaginable workload, and it seems like this
>> can't really be wo
On Fri, Dec 16, 2011 at 8:25 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On that theory, I'm inclined to think that's not really a problem.
>> We'll go nuts if we refuse to commit anything until it shows a
>> meaningful win on every imaginable workload, and it seems like this
>> can't really
Robert Haas wrote:
> On that theory, I'm inclined to think that's not really a problem.
> We'll go nuts if we refuse to commit anything until it shows a
> meaningful win on every imaginable workload, and it seems like this
> can't really be worse than the status quo; any case where it is must
> be
On Thu, Dec 15, 2011 at 11:35 PM, Robert Haas wrote:
> One small detail I'm noticing on further review is that I've slightly
> changed the semantics here:
>
> if (!TransactionIdIsNormal(xid)
> || NormalTransactionIdPrecedes(xmax, xid))
> continue;
>
> T
On Mon, Nov 7, 2011 at 7:28 AM, Robert Haas wrote:
> On Mon, Nov 7, 2011 at 6:45 AM, Heikki Linnakangas
> wrote:
>> While looking at GetSnapshotData(), it occurred to me that when a PGPROC
>> entry does not have its xid set, ie. xid == InvalidTransactionId, it's
>> pointless to check the subxid a
On Thu, Nov 24, 2011 at 11:54 PM, Pavan Deolasee
wrote:
> +1. These are independent patches and should be pursued like that.
> BTW, I reviewed the pgxact-v2.patch and I have no objections to that
> and it looks good to go in. Thanks Robert for making the necessary
> changes and also running the be
On Thu, Nov 24, 2011 at 7:24 PM, Simon Riggs wrote:
> On Thu, Nov 24, 2011 at 1:30 PM, Robert Haas wrote:
>
>> I'm going to run some more tests, but my thought is that we should
>> probably leave the recentglobalxmin changes out for the time being,
>> pending further study and consideration of ot
On Thu, Nov 24, 2011 at 1:30 PM, Robert Haas wrote:
> I'm going to run some more tests, but my thought is that we should
> probably leave the recentglobalxmin changes out for the time being,
> pending further study and consideration of other alternatives.
Agreed
--
Simon Riggs
On Mon, Nov 7, 2011 at 6:45 AM, Heikki Linnakangas
wrote:
> While looking at GetSnapshotData(), it occurred to me that when a PGPROC
> entry does not have its xid set, ie. xid == InvalidTransactionId, it's
> pointless to check the subxid array for that proc. If a transaction has no
> xid, none of
On 04.11.2011 00:43, Simon Riggs wrote:
On Thu, Nov 3, 2011 at 6:12 PM, Pavan Deolasee wrote:
When PGPROC array is allocated, we also allocate another array of
PGPROC_MINIMAL structures of the same size. While accessing the
ProcArray, a simple pointer mathematic can get us the corresponding
PG
On Fri, Nov 4, 2011 at 4:13 AM, Simon Riggs wrote:
>
> If you look at your PGPROC_MINIMAL, its mostly transaction related
> stuff, so I would rename it PGXACT or similar.
Yeah, that looks good too. Though I am not sure if all fields are
related to transaction state and whether we would need to a
On Thu, Nov 3, 2011 at 6:12 PM, Pavan Deolasee wrote:
> When PGPROC array is allocated, we also allocate another array of
> PGPROC_MINIMAL structures of the same size. While accessing the
> ProcArray, a simple pointer mathematic can get us the corresponding
> PGPROC_MINIMAL structure. The only ex
Hi All,
While working on some of the performance issues on HP-UX, I noticed a
significant data cache misses for accessing PGPROC members. On a close
inspection, it was quite evident that for large number (even few 10s)
of clients, the loop inside GetSnapshotData will cause data cache miss
for almo
14 matches
Mail list logo
