remove useless ccache searching

Pavel, I have not taken on your patch for review, but I was reading the history of it, and one question popped up:

If you are allocating a new cache, what if the array is really big, will 1st cache + your cache get bigger than work_mem? (or are array op's not constrained by work_mem? Sorry, I have not used array's so not sure if there are memory limits on them)

-Andy

Hello

2011/9/5 Andy Colson <andy@squeakycode.net>:

This patch:

https://commitfest.postgresql.org/action/patch_view?id=597

caches the cache because, I guess, the cache is slow.

Simon asked, "What is making the first cache so slow?".  Pavel does not
know, nor how to fix it, and nobody else responded.

So my question is: is someone going to take a look at the cache?  Should
this be accepted as a short term fix (cuz someone will fix the cache later),
long term fix (cuz the cache needs to say as-is), or not at all (because
someone will fix cache right now now)?

A idea so this patch is cache of cache is not exact

Access to array needs lot of metadata related to element type. These
metadata are statics. I can store these data when we first access a
variable with data. ccache is relative fast - hash search, but should
not be faster than just direct access to structure. This technique is
used more time in PL/pgSQL.

Regards

Pavel

Hello

2011/9/5 Andy Colson <andy@squeakycode.net>:

Pavel, I have not taken on your patch for review, but I was reading the
history of it, and one question popped up:

If you are allocating a new cache, what if the array is really big, will 1st
cache + your cache get bigger than work_mem?  (or are array op's not
constrained by work_mem?  Sorry, I have not used array's so not sure if
there are memory limits on them)

this patch doesn't cache a array - it store only a 18 bytes more per
array variable - it doesn't depend on array size.

but generally, arrays are not limited by work_mem - so if you work
with large arrays - you can go out of memory.

Regards

Pavel

Andy Colson <andy@squeakycode.net> writes:

This patch:
https://commitfest.postgresql.org/action/patch_view?id=597

caches the cache because, I guess, the cache is slow.

Simon asked, "What is making the first cache so slow?". Pavel does not know, nor how to fix it, and nobody else responded.

Well, the cache doesn't need to be "slow" to make it worthwhile to
eliminate repeated cache lookups altogether. We do that in many places.

The questions that need to be asked here are whether the speed gain is
worthwhile, whether there is any possibility of the locally cached
information becoming obsolete, whether it's done in a clean fashion,
whether it should be done somewhere else instead of right here.

regards, tom lane