On Wed, 4 Jun 2025 at 16:18, Fujii Masao
wrote:
>
> Regardless, I think we should go ahead and apply the current patch.
>
Yeah, it is definitely improving things. It turns out that I made almost
the same
patch for our fork of Postgres, commissioned by one of the clients dealing
with
truncation o
On 2025/06/02 18:06, Yura Sokolov wrote:
31.05.2025 17:23, Daniil Davydov пишет:
Hi,
On Sat, May 31, 2025 at 7:41 PM Fujii Masao wrote:
Here are a few review comments on the patch:
+ for (j = 0; j < nforks; j++)
{
- InvalidateLocalBuff
31.05.2025 17:23, Daniil Davydov пишет:
> Hi,
>
> On Sat, May 31, 2025 at 7:41 PM Fujii Masao
> wrote:
>>
>> Here are a few review comments on the patch:
>>
>> + for (j = 0; j < nforks; j++)
>> {
>> - InvalidateLocalBuffer(bufHdr, true);
>> +
Hi,
On Mon, Jun 2, 2025 at 11:14 AM Dilip Kumar wrote:
>
> > (I haven't figured out how to force postgres to
> > create a visibility map for temp table within the transaction block).
>
> I haven't tested this, but I think if you do bulk copy into a table
> which should mark pages all visible and
On Sun, Jun 1, 2025 at 5:51 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Sun, Jun 1, 2025 at 5:31 PM Dilip Kumar wrote:
> >
> > On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
> > >
> > > I doubt that it would be a good idea to apply a patch "just" because
> > > it looks l
On 2025/05/31 23:23, Daniil Davydov wrote:
Hi,
On Sat, May 31, 2025 at 7:41 PM Fujii Masao wrote:
Here are a few review comments on the patch:
+ for (j = 0; j < nforks; j++)
{
- InvalidateLocalBuffer(bufHdr, true);
+
Hi,
On Sun, Jun 1, 2025 at 5:31 PM Dilip Kumar wrote:
>
> On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
> >
> > I doubt that it would be a good idea to apply a patch "just" because
> > it looks like a good idea. It is important to prove that something is
> > a good idea first.
>
> I thi
On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
>
> On Sat, May 31, 2025 at 01:26:14PM +0700, Daniil Davydov wrote:
> > Not yet. I proceed from the assumption that if the temp_buffers
> > parameter is set to a large value (some users set it to more than a
> > gigabyte), then the vast majorit
On Sat, May 31, 2025 at 01:26:14PM +0700, Daniil Davydov wrote:
> Not yet. I proceed from the assumption that if the temp_buffers
> parameter is set to a large value (some users set it to more than a
> gigabyte), then the vast majority of time is spent iterating through
> the local buffers.
> Thus,
Hi,
On Sat, May 31, 2025 at 7:41 PM Fujii Masao wrote:
>
> Here are a few review comments on the patch:
>
> + for (j = 0; j < nforks; j++)
> {
> - InvalidateLocalBuffer(bufHdr, true);
> + if ((buf_state & BM_TAG_VALID) &&
>
On 2025/05/31 15:26, Daniil Davydov wrote:
Hi,
On Sat, May 31, 2025 at 7:49 AM Michael Paquier wrote:
On Fri, May 30, 2025 at 06:01:16PM +0700, Daniil Davydov wrote:
For now we fully scan local buffers for each fork of the temporary
relation that we want to truncate (in order to drop its
Hi,
On Sat, May 31, 2025 at 7:49 AM Michael Paquier wrote:
>
> On Fri, May 30, 2025 at 06:01:16PM +0700, Daniil Davydov wrote:
> > For now we fully scan local buffers for each fork of the temporary
> > relation that we want to truncate (in order to drop its buffers). It
> > happens in the functio
On Fri, May 30, 2025 at 06:01:16PM +0700, Daniil Davydov wrote:
> For now we fully scan local buffers for each fork of the temporary
> relation that we want to truncate (in order to drop its buffers). It
> happens in the function "DropRelationBuffers".
> There used to be the same problem for regula
13 matches
Mail list logo
