Re: [patch] libpq one-row-at-a-time API

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [patch] libpq one-row-at-a-time API
Дата
Msg-id 23861.1343149153@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [patch] libpq one-row-at-a-time API  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: [patch] libpq one-row-at-a-time API  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
> I think the dummy copy of PGresult is plausible (if by that you mean
> optimizing PQgetResult when in single row mode).  That would be even
> better: you'd remove the need for the rowbuf mode.

I haven't spent any time looking at this, but my gut tells me that a big
chunk of the expense is copying the PGresult's metadata (the column
names, types, etc).  It has to be possible to make that cheaper.

One idea is to rearrange the internal storage so that that part reduces
to one memcpy().  Another thought is to allow PGresults to share
metadata by treating the metadata as a separate reference-counted
object.  The second could be a bit hazardous though, as we advertise
that PGresults are independent objects that can be manipulated by
separate threads.  I don't want to introduce mutexes into PGresults,
but I'm not sure reference-counted metadata can be safe without them.
So maybe the memcpy idea is the only workable one.
        regards, tom lane


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

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: [patch] libpq one-row-at-a-time API
Следующее
От: karavelov@mail.bg
Дата:
Сообщение: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)