Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Дата
Msg-id bde2f89f-c0b2-a8e9-126a-ac3686f0cbb0@dunslane.net
обсуждение исходный текст
Ответ на Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Ответы Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Список pgsql-hackers
On 2022-08-09 Tu 15:50, Jonathan S. Katz wrote:
> On 8/9/22 3:22 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2022-08-09 15:17:44 -0400, Tom Lane wrote:
>>> We have delayed releases for $COOL_FEATURE in the past, and I think
>>> our batting average on that is still .000: not once has it worked out
>>> well.
>>
>> I think it semi worked when jsonb (?) first went in - it took a while
>> and a
>> lot of effort from a lot of people, but in the end we made it work,
>> and it was
>> a success from our user's perspectives, I think. 
>
> Yeah, this was the example I was thinking of. To continue with the
> baseball analogy, it was a home-run from a PR perspective, and I can
> say as a power user at the time, the 9.4 JSONB representation worked
> well for my use case. Certainly newer functionality has made JSON
> easier to work with in PG.
>
> (I can't remember what the 9.5 hold up was).
>
> The cases where we either delayed/punted on $COOL_FEATURE that cause
> me concern are the ones where we say "OK, well fix this in the next
> release" and we are then waiting, 2, 3, 4 releases for the work to be
> completed. And to be clear, I'm thinking of this as "known issues" vs.
> "iterating towards the whole solution".


Where we ended up with jsonb was a long way from where we started, but
technical difficulties were largely confined because it didn't involve
anything like the parser or the expression evaluation code. Here the SQL
Standards Committee has imposed a pretty substantial technical burden on
us and the code that Andres complains of is attempting to deal with that.


>
>> OTOH, it's not a great sign  this is around json again...
>
> Yeah, I was thinking about that too.


Ouch :-(

I think after 10 years of being involved with our JSON features, I'm
going to take a substantial break on that front.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: optimize lookups in snapshot [sub]xip arrays
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size