Re: Most efficient way for libPQ .. PGresult serialization
| От | Craig Ringer |
|---|---|
| Тема | Re: Most efficient way for libPQ .. PGresult serialization |
| Дата | |
| Msg-id | CAMsr+YFTdijVGaE-VzkuAAn6f5L1RZ07h+C+Tk2ZjpoxYn+b_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Most efficient way for libPQ .. PGresult serialization (Joshua Bay <joshuabay93@gmail.com>) |
| Ответы |
Re: Most efficient way for libPQ .. PGresult serialization
|
| Список | pgsql-hackers |
On 19 August 2016 at 22:16, Joshua Bay <joshuabay93@gmail.com> wrote:
Oh I see.I just read more on use cases PgBouncer, but seems like it can't be used for my project.The reason is that I need to have my middleware to have full control over each transaction.That is it must be able to decide if it's going to commit or abort a single query (reason why libpq is used in the middleware), and it must be able to decide when to send back the result. Also it does things like load balancing with it's algorithm.So, what middleware does is (simplied, ignoring other details)1. listens to query and does load balancing2. execute query on behalf of client to server with libpq (does not have to be libpq).3. serialize the result and send it backAnd the #3 is why I asked for ways to serialize PGresult (of libpq)Client app will deserialize the result and thus be able to interpret PGresult as if it used libpq itself.
Surely the app should just use libpq, and your middleware should be a proxy?
Like, say, PgPool-II?
Otherwise you'll have to extract all the results handling parts of libpq into some smaller cut-down library and graft on serialization/deserialization code. There's nothing built-in for that ,since the natural and logical serialization for query results is the PostgreSQL wire protocol.
В списке pgsql-hackers по дате отправления: