Re: copy vs. C function

Поиск
Список
Период
Сортировка
От Jon Nelson
Тема Re: copy vs. C function
Дата
Msg-id CAKuK5J0OPwnqdsWBYQ7nV7nAzev0VW8WW5K9QnjnH7QNbFpGiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: copy vs. C function  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: copy vs. C function  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Список pgsql-performance
On Wed, Dec 14, 2011 at 9:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jon Nelson <jnelson+pgsql@jamponi.net> writes:
>> Regarding caching, I tried caching it across calls by making the
>> TupleDesc static and only initializing it once.
>> When I tried that, I got:
>
>> ERROR:  number of columns (6769856) exceeds limit (1664)
>
>> I tried to find some documentation or examples that cache the
>> information, but couldn't find any.
>
> You might find reading record_in to be helpful.  What it caches is not
> exactly what you need to, I think, but it shows the general principles.
> There are lots of other functions that use fn_extra to cache info, too.

I will definitely look into those. I'm probably doing it wrong, but in
the meantime, I allocated enough space (by way of MemoryContextAlloc)
in TopMemoryContext for an AttInMetadata pointer, switched to that
memory context (just the first time through), used CreateTupleDescCopy
+ TupleDescGetAttInMetadata to duplicate (in the new memory context)
the TupleDesc, and then switched back. This approach seems to have
dropped the total run time to about 54 seconds, the bulk of which is
BuildTupleFromCStrings, a rather significant improvement.

....

Looking at record_in, I think I see what I could be doing better.

Again, thanks for the pointers.


--
Jon

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: copy vs. C function
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: copy vs. C function