Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns
Дата
Msg-id 20171011155410.ommeaiuyy5gtmsz4@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 2017-10-11 10:53:56 +0200, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hi,
> > 
> > On 2017-10-03 13:58:37 -0400, Robert Haas wrote:
> > > On Tue, Oct 3, 2017 at 12:23 PM, Andres Freund <andres@anarazel.de> wrote:
> > > > Makes sense?
> > > 
> > > Yes.
> > 
> > Here's an updated version of this patchset.
> 
> Maybe it'd be a good idea to push 0001 with some user of restrict ahead
> of the rest, just to see how older msvc reacts.

Can do. Not quite sure which older user yet, but I'm sure I can find
something.


> I wonder if it'd be a good idea to nag external users about pq_sendint
> usage (is a #warning possible?).

Think we'd need some separate infrastructure, i.e. for gcc ending up
with __attribute__((deprecated)). I don't quite see this being worth
adding it, but ...


> OTOH, do we really need to keep it
> around?  Maybe we should ditch it, since obviously the compat shim can
> be installed locally in each extension that really needs it (thinking
> that most external code can simply be adjusted to the new functions).

That seems like causing unnecessary pain - we're talking about a few
lines in a header here, right? It's not like they'll be trivially
converting to pq_sendint$width anytime soon, unless we backpatch this.


> I'm scared about the not-null-terminated stringinfo stuff.  Is it
> possible to create bugs by polluting a stringinfo with it, then having
> the stringinfo be used by unsuspecting code?  Admittedly, you can break
> things already with the binary appends, so probably not an issue.

All of the converted sites already add integers into the StringInfo -
and most of the those integers consist out of a couple bytes of 0,
because they're lengths. So I don't think there's a huge danger here.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] Predicate Locks for writes?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] parallelize queries containing initplans