Jan Wieck writes:
> On 09/18/2015 10:47 AM, Tom Lane wrote:
>> Attached is something closer to what I was envisioning; can you do
>> performance testing on it?
> Yes, that patch also has the desired performance for restoring a schema
> with hundreds of thousands of foreign key
Tom Lane wrote:
> Jan Wieck writes:
> > Attached is a complete rework of the fix from scratch, based on Tom's
> > suggestion.
>
> > The code now maintains a double linked list as suggested, but only uses
> > it to mark all currently valid entries as invalid when hashvalue ==
Alvaro Herrera writes:
> Would it make sense to remove the only the few oldest entries, instead
> of all of them? As is, I think this causes a storm of reloads every
> once in a while, if the number of FKs in the system is large enough.
> Maybe on a cache hit we could
I wrote:
> Alvaro Herrera writes:
>> Would it make sense to remove the only the few oldest entries, instead
>> of all of them? As is, I think this causes a storm of reloads every
>> once in a while, if the number of FKs in the system is large enough.
>> Maybe on a cache
On 09/18/2015 10:47 AM, Tom Lane wrote:
Jan Wieck writes:
Attached is a complete rework of the fix from scratch, based on Tom's
suggestion.
The code now maintains a double linked list as suggested, but only uses
it to mark all currently valid entries as invalid when
Jan Wieck writes:
> Attached is a complete rework of the fix from scratch, based on Tom's
> suggestion.
> The code now maintains a double linked list as suggested, but only uses
> it to mark all currently valid entries as invalid when hashvalue == 0.
> If a specific entry is
On 09/15/2015 12:02 PM, Jan Wieck wrote:
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
I wrote:
> Jan Wieck writes:
>> I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
>> definitely is caused by this commit. Do you want to back it out for the
>> time being? Kevin is on vacation right now.
> I'll take a look today, and either fix it if I can
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
Another idea is that it's not the size
Jan Wieck writes:
> Would it be appropriate to use (Un)RegisterXactCallback() in case of
> detecting excessive sequential scanning of that cache and remove all
> invalid entries from it at that time?
Don't see how unregistering the callback would help?
In any case, I'm -1 on
On 09/15/2015 10:58 AM, Tom Lane wrote:
I wrote:
Jan Wieck writes:
I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
definitely is caused by this commit. Do you want to back it out for the
time being? Kevin is on vacation right now.
I'll take a look
Jan Wieck writes:
> On 09/14/2015 09:56 AM, Tom Lane wrote:
>> Kevin Grittner writes:
>>> Fix an O(N^2) problem in foreign key references.
>> Judging from the buildfarm, this patch is broken under
>> CLOBBER_CACHE_ALWAYS. See friarbird's results in
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I might be too quick to finger this
On 09/15/2015 09:51 AM, Tom Lane wrote:
Jan Wieck writes:
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS.
Kevin Grittner writes:
> Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I might be too quick to finger this patch, but nothing else
lately has touched
15 matches
Mail list logo