Hi,
> > So we're really quite surprised that it has got so little feedback. We've
> > got
> > some opinions on approach but there is no any general one on the approach
> > itself except doubts about the TOAST mechanism needs revision at all.
>
> The problem for me is that what you've been posting doesn't actually fix
> any problem, but instead introduces lots of new code and complexity.
> > Currently we're busy revising the whole Pluggable TOAST API to make it
> > available as an extension and based on hooks to minimize changes in
> > the core. It will be available soon.
>
> I don't think we should accept that either. It still doesn't improve
> anything about toast, it just allows you to do such improvements out of
> core.
Agree. On top of that referencing non-reproducible benchmarks doesn't
help. There were some slides referenced in the thread but I couldn't
find exact steps to reproduce the benchmarks.
Your desire to improve the TOAST mechanism is much appreciated. I
believe we are all on the same side here, the one where people work
together to make PostgreSQL an even better DBMS.
However in order to achieve this firstly a consensus within the
community should be reached about how exactly we are going to do this.
Afterwards, all the code and benchmarks should be made publicly
available under a proper license so that anyone could explore and
reproduce them. Last but not least, the complexity should really be
taken into account. There are real people who are going to maintain
the code after (and if) it will be merged, and there are not so many
of them.
The problems I see are that the type-aware TOASTers skipped step (1)
right to the step (2) and doesn't seem to consider (3). Even after it
was explicitly pointed out that we should take a step back and return
to (1).
--
Best regards,
Aleksander Alekseev