On Tue, 14 Nov 2023, 14:12 Nikita Malakhov, wrote:
>
> Hi!
>
> Matthias, regarding your message above, I have a question to ask.
> On typed TOAST implementations - we thought that TOAST method used
> for storing data could depend not only on data type, but on the flow or
> workload,
> like out by
Hi!
Matthias, regarding your message above, I have a question to ask.
On typed TOAST implementations - we thought that TOAST method used
for storing data could depend not only on data type, but on the flow or
workload,
like out bytea appendable toaster which is much (hundreds of times) faster
on
u
On Tue, 7 Nov 2023 at 11:06, Nikita Malakhov wrote:
>
> Hi,
>
> I've been thinking about Matthias' proposals for some time and have some
> questions:
>
> >So, in short, I don't think there is a need for a specific "Pluggable
> >toast API" like the one in the patchset at [0] that can be loaded
> >o
Hi,
I've been thinking about Matthias' proposals for some time and have some
questions:
>So, in short, I don't think there is a need for a specific "Pluggable
>toast API" like the one in the patchset at [0] that can be loaded
>on-demand, but I think that updating our current TOAST system to a
>sy
Hi!
Matthias, thank you for your patience and explanation. I'd wish I had it
much earlier, it would save a lot of time.
You've asked a lot of good questions, and the answers we have for some
seem to be not very satisfactory, and pointed out some topics that were not
mentioned before. I have to ret
On Thu, 26 Oct 2023 at 15:18, Aleksander Alekseev
wrote:
>
> Hi,
>
> > And the goal of *THIS* topic is to gather a picture on how the community
> > sees
> > improvements in TOAST mechanics if it doesn't want it the way we proposed
> > before, to understand which way to go with JSON advanced stora
On Tue, 24 Oct 2023 at 22:38, Nikita Malakhov wrote:
>
> Hi hackers!
>
> We need community feedback on previously discussed topic [1].
> There are some long-live issues in Postgres related to the TOAST mechanics,
> like [2].
> Some time ago we already proposed a set of patches with an API allowin
Hi,
> And the goal of *THIS* topic is to gather a picture on how the community sees
> improvements in TOAST mechanics if it doesn't want it the way we proposed
> before, to understand which way to go with JSON advanced storage and other
> enhancements we already have. Previous topic was not of any
Hi,
I meant discussion preceding the patch set - there was no any.
And the goal of *THIS* topic is to gather a picture on how the community
sees
improvements in TOAST mechanics if it doesn't want it the way we proposed
before, to understand which way to go with JSON advanced storage and other
enh
Hi,
> Aleksander, previous discussion was not a discussion actually, we proposed
> a set of big and complex core changes without any discussion preceding it.
> That was not very good approach although the overall idea behind the patch
> set is very progressive and is ready to solve some old and pa
Hi,
Aleksander, previous discussion was not a discussion actually, we proposed
a set of big and complex core changes without any discussion preceding it.
That was not very good approach although the overall idea behind the patch
set is very progressive and is ready to solve some old and painful is
Hi Nikita,
> We need community feedback on previously discussed topic [1].
> There are some long-live issues in Postgres related to the TOAST mechanics,
> like [2].
> Some time ago we already proposed a set of patches with an API allowing to
> plug in
> different TOAST implementations into a liv
12 matches
Mail list logo
