On Thu, Jan 16, 2025 at 4:43 PM Melanie Plageman
wrote:
>
> On Fri, Oct 25, 2024 at 11:14 AM Melanie Plageman
> wrote:
> >
> > I've done something similar to this in attached v2.
>
> This needed a rebase. See attached v4.
Whoops -- docs didn't build. Atta
On Fri, Oct 25, 2024 at 11:14 AM Melanie Plageman
wrote:
>
> I've done something similar to this in attached v2.
This needed a rebase. See attached v4.
- Melanie
v4-0001-Add-relallfrozen-to-pg_class.patch
Description: Binary data
v4-0002-Trigger-more-frequent-autov
On Sun, Dec 15, 2024 at 10:10 AM Tomas Vondra wrote:
>
> I've been looking at some other vacuum-related patches, so I took a look
> at these remaining bits too. I don't have much to say about the code
> (seems perfectly fine to me), so I decided to do a bit of testing.
Thanks for doing this!
> I
On Wed, Jan 15, 2025 at 3:03 PM Melanie Plageman
wrote:
>
> On Wed, Jan 15, 2025 at 2:36 PM Marcos Pegoraro wrote:
> >>
> > There is a typo on committed vacuumlazy.c file
> > * If the TID store fills up in phase I, vacuum suspends phase I, proceeds
> > to
>
On Wed, Jan 15, 2025 at 12:08 PM Alena Rybakina
wrote:
>
> This is interesting, but I think it might belong as commentary in
> vacuumparallel.c instead.
>
> I added some description about it, I hope it is fine. I attached
> vacuum_description.diff
Alena, thanks again for your review. I pushed th
On Wed, Jan 15, 2025 at 2:36 PM Marcos Pegoraro wrote:
>>
>> On 14.01.2025 22:51, Melanie Plageman wrote:
>
>
> There is a typo on committed vacuumlazy.c file
> * If the TID store fills up in phase I, vacuum suspends phase I, proceeds to
> * phases II and II,
On Tue, Jan 14, 2025 at 2:30 PM Alena Rybakina
wrote:
>
> Looking at them, I am willing to agree with you
Cool. Thanks to everyone for the review. I've pushed it.
- Melanie
hink it might belong as commentary in
vacuumparallel.c instead.
Thanks again for your close reading and detailed thoughts!
- Melanie
From d579e6fa22982f66b7e23efc80e7e528d2059d51 Mon Sep 17 00:00:00 2001
From: Melanie Plageman
Date: Tue, 7 Jan 2025 09:48:34 -0500
Subject: [PATCH v7 2/2] Eagerly
On Tue, Jan 14, 2025 at 1:21 PM Alvaro Herrera wrote:
>
> On 2025-Jan-13, Melanie Plageman wrote:
>
> > I've gone with VACUUM_AUTOVACUUM, VACUUM_COST_DELAY, and
> > VACUUM_FREEZING, but I am open to feedback.
>
> Looks good to me. I checked these two queries
On Mon, Jan 13, 2025 at 3:46 PM Alvaro Herrera wrote:
>
> On 2025-Jan-13, Melanie Plageman wrote:
>
> > Since I didn't hear back about this and I don't see an obvious
> > alternative reorganization in guc_tables.c, I plan to just push the
>
On Thu, Jan 9, 2025 at 1:24 PM Andres Freund wrote:
>
> On 2025-01-07 15:46:26 -0500, Melanie Plageman wrote:
> > For table storage options, those related to vacuum but not autovacuum
> > are in the main StdRdOptions struct. Of those, some are overridden by
> > VACUUM comm
On Mon, Jan 13, 2025 at 10:22 AM Melanie Plageman
wrote:
>
> Thanks to Álvaro for pointing this out. I didn't think of it.
>
> On Sun, Jan 12, 2025 at 2:21 PM Tom Lane wrote:
> >
> > Daniel Gustafsson writes:
> > > On 11 Jan 2025, at 10:02, Alvaro Herrera
On Sat, Jan 11, 2025 at 7:42 PM Tomas Vondra wrote:
>
> I had a quiet evening yesterday, so I decided to take a stab at this and
> see how hard would it be, and how bad would the impact be. Attached is
> an experimental patch, doing the *bare* minimum for a simple query:
>
> 1) It defines a limit
Thanks to Álvaro for pointing this out. I didn't think of it.
On Sun, Jan 12, 2025 at 2:21 PM Tom Lane wrote:
>
> Daniel Gustafsson writes:
> > On 11 Jan 2025, at 10:02, Alvaro Herrera wrote:
> >> and the GUC grouping in guc_tables.c/h?
>
> > I don't know what our policy around this is, and may
On Fri, Jan 10, 2025 at 6:00 PM Daniel Gustafsson wrote:
>
> > On 10 Jan 2025, at 23:09, Melanie Plageman
> > wrote:
> >
> > On Thu, Jan 9, 2025 at 5:05 PM Daniel Gustafsson wrote:
> >>
> >> I think this is a really good restructuring which will mak
On Fri, Jan 10, 2025 at 11:18 AM Tomas Vondra wrote:
>
> On 1/10/25 15:54, Melanie Plageman wrote:
> > On Thu, Jan 9, 2025 at 6:59 PM Tomas Vondra wrote:
> > I think this is because we get the batch based on
> >
> > *batchno = pg_rotate_right32(hashvalue, hashtable
On Thu, Jan 9, 2025 at 5:05 PM Daniel Gustafsson wrote:
>
> I think this is a really good restructuring which will make life easier for
> our
> users. Some of the comments below are on wording which wasn't introduced in
> this patch, but which I hadn't thought about before, so feel free to ignor
On Thu, Jan 9, 2025 at 6:59 PM Tomas Vondra wrote:
>
>
>
> On 1/9/25 21:42, Melanie Plageman wrote:
> >
> > I was excited about your raw file experiment. As Robert and you point
> > out -- we may need a file per batch, but for most of the hash join's
> >
On Sun, Jan 5, 2025 at 10:00 PM Tomas Vondra wrote:
>
> I think the general idea and formula explained in [1] is right, but
> while working on the PoC patch I started to think about how to formalize
> this. And I ended up creating two tables that I think visualize is
> pretty nicely.
>
> Imagine a
On Tue, Dec 31, 2024 at 6:07 PM Tomas Vondra wrote:
>
> This means that ultimately it's either (1) or (3), and the more I've
> been looking into this the more I prefer (1), for a couple reasons:
>
> * It's much simpler (it doesn't really change anything on the basic
> behavior, doesn't introduce a
On Tue, Dec 31, 2024 at 6:07 PM Tomas Vondra wrote:
>
> So I decided to revisit the three patches from 2019. Attached are
> rebased and cleaned up versions. A couple comments on each one:
>
>
> 1) v20241231-adjust-limit-0001-Account-for-batch-files-in-ha.patch
>
> I believe this is the way to go,
On Wed, Jan 8, 2025 at 8:39 AM Peter Eisentraut wrote:
>
> On 07.01.25 18:31, Melanie Plageman wrote:
> >
> > Oh, one thing I forgot to say. Though I increased the indentation of
> > some of the subsections that I moved, I didn't rewrap the lines
> > because the
On Wed, Jan 8, 2025 at 6:35 AM Daniel Gustafsson wrote:
>
> > On 7 Jan 2025, at 21:14, Tom Lane wrote:
>
> > I might be wrong, but I had the idea that our docs website has a
> > capability to provide such redirects. You'd probably need to ask
> > about that on the pgsql-www list, unless somebody
On Mon, Dec 23, 2024 at 12:50 PM Melanie Plageman
wrote:
>
> The other "worst case" is just that you always scan and fail to freeze
> an extra 3% of the relation while vacuuming the table. This one is
> much easier to achieve. As such, it seems worthwhile to add a GUC and
On Tue, Jan 7, 2025 at 12:15 PM Melanie Plageman
wrote:
>
> Cool, I've attached a patch to do this. I left a few of the GUCs under
> Resource Consumption (like autovacuum_work_mem and
> vacuum_buffer_usage_limit) where they are because it seemed
> appropriate.
>
> This i
On Mon, Jan 6, 2025 at 8:26 PM Tom Lane wrote:
>
> Melanie Plageman writes:
> > I was reviewing all the vacuum related GUCs, and I noticed that they
> > fall into three main subsections of Chapter 19 (Server Configuration)
> > in the docs [1]: Automatic Vacuuming [2],
I was reviewing all the vacuum related GUCs, and I noticed that they
fall into three main subsections of Chapter 19 (Server Configuration)
in the docs [1]: Automatic Vacuuming [2], Resource Consumption [3],
and Client Connection Defaults [4]. The last one I find pretty
confusing.
vacuum_freeze_min
On Sat, Dec 21, 2024 at 10:28 AM Robert Treat wrote:
>
> On Tue, Dec 17, 2024 at 5:51 PM Melanie Plageman
> wrote:
> >
> It feels to me like eager vacuums are not so much a distinct thing,
> but that, like how all vacuum do index cleanup unless told not to, all
> vacuums
Updated v4 attached.
On Wed, Dec 18, 2024 at 4:30 PM Robert Haas wrote:
>
> On Tue, Dec 17, 2024 at 5:54 PM Melanie Plageman
> wrote:
> > Makes sense. I've attempted to clarify as you suggest in v3.
>
> I would just commit 0001. There's nothing to be gained by wa
On Thu, Dec 19, 2024 at 9:36 PM Richard Guo wrote:
>
> On Fri, Dec 20, 2024 at 7:50 AM Melanie Plageman
> wrote:
> Looks correct to me.
>
> BTW, I kind of doubt that the overflow risk fixed in 28328ec87 is a
> real issue in real-world scenarios. Is it realistically possibl
On Wed, Dec 18, 2024 at 9:50 PM Richard Guo wrote:
>
> On Thu, Dec 19, 2024 at 8:18 AM Melanie Plageman
> wrote:
> > I pushed the straightforward option for now so that it's fixed.
>
> I think this binary search code now has a risk of underflow. If 'mid'
>
On Thu, Dec 19, 2024 at 10:23 AM Melanie Plageman
wrote:
>
> On Thu, Dec 19, 2024 at 10:12 AM Richard Guo wrote:
> >
> > On Thu, Dec 19, 2024 at 6:15 PM Richard Guo wrote:
> > > I think we need to check whether rs_tbmiterator is NULL before calling
> > &g
On Thu, Dec 19, 2024 at 10:12 AM Richard Guo wrote:
>
> On Thu, Dec 19, 2024 at 6:15 PM Richard Guo wrote:
> > I think we need to check whether rs_tbmiterator is NULL before calling
> > tbm_end_iterate on it, like below.
> >
> > --- a/src/backend/executor/nodeBitmapHeapscan.c
> > +++ b/src/backen
On Wed, Dec 18, 2024 at 3:13 PM Melanie Plageman
wrote:
>
> option 1:
> most straightforward fix
>
> diff --git a/src/backend/access/heap/heapam_handler.c
> b/src/backend/access/heap/heapam_handler.c
> index d0e5922eed7..fa03bedd4b8 100644
> --- a/src/backend/access/heap/
On Wed, Dec 18, 2024 at 1:23 PM Ranier Vilela wrote:
>
> Hi.
>
> Em qua., 18 de dez. de 2024 às 14:01, Melanie Plageman
> escreveu:
>>
>> For now, I've committed the version of the patch I proposed above (v3).
>
> What happens if *rs_tuples* equal to zero
On Mon, Oct 28, 2024 at 2:27 AM Dilip Kumar wrote:
>
> On Sat, Oct 26, 2024 at 5:30 PM Melanie Plageman
> wrote:
>>
>> Yes, so in the case of backwards scan, if scan->rs_cindex is 0, when
>> dir is -1, lineindex will wrap around, but we don't use it in that
Thanks for the review!
On Tue, Dec 17, 2024 at 10:57 AM Nazir Bilal Yavuz wrote:
>
> Here are couple of code comments:
>
> === [PATCH v2 07/10] ===
>
> It took me a while to understand that heap_vac_scan_next_block() loops
> until rel_pages. What do you think about adding
> Assert(vacrel->current
On Tue, Dec 17, 2024 at 1:46 PM Tomas Vondra wrote:
>
> On 12/17/24 18:06, Melanie Plageman wrote:
> > On Tue, Dec 17, 2024 at 9:11 AM Tomas Vondra wrote:
> >>
> >>
> >>
> >> On 12/16/24 19:49, Melanie Plageman wrote:
> >>
> >&g
On Mon, Dec 16, 2024 at 7:14 PM Melanie Plageman
wrote:
>
> On Wed, Dec 11, 2024 at 2:18 PM Masahiko Sawada wrote:
> >
> > I agree that it will be unimportant from Melanie's work in this area.
> > Also, I agree that if semi-aggressive vacuum has its own new loggin
On Tue, Dec 17, 2024 at 9:11 AM Tomas Vondra wrote:
>
>
>
> On 12/16/24 19:49, Melanie Plageman wrote:
>
> > No, I'm talking about the behavior of causing small pockets of
> > all-frozen pages which end up being smaller than SKIP_PAGES_THRESHOLD
> > and
On Mon, Dec 16, 2024 at 2:18 PM Peter Geoghegan wrote:
>
> On Mon, Dec 16, 2024 at 1:50 PM Melanie Plageman
> wrote:
> > Then in the next vacuum, we end up scanning those all-frozen pages again
> > because the
> > ranges of frozen pages are smaller than SKIP_PAGES_TH
On Thu, Dec 12, 2024 at 9:39 PM Tomas Vondra wrote:
>
> On 12/11/24 20:18, Masahiko Sawada wrote:
> >
> > ...
> >
> >> Here's an example to exercise the new log message:
> >>
> >> create table foo (a int, b int) with (autovacuum_enabled = false);
> >> insert into foo select generate_series(1,1000)
On Wed, Dec 11, 2024 at 2:18 PM Masahiko Sawada wrote:
>
> On Thu, Dec 5, 2024 at 4:32 PM Melanie Plageman
> wrote:
> >
> > On Mon, Dec 2, 2024 at 9:28 AM Robert Haas wrote:
> > >
> > >
> > > All that said, if you really want this broken out into
e of ticks is platform dependent and so the caller
is responsible for not passing it values that would overflow when
subtracted.
- Melanie
From f6fa312b605fac31463acc90446aad6afd6933ec Mon Sep 17 00:00:00 2001
From: Melanie Plageman
Date: Tue, 3 Dec 2024 18:02:15 -0500
Subject: [PATCH v1] Add
On Mon, Dec 16, 2024 at 12:32 PM Peter Geoghegan wrote:
>
> On Mon, Dec 16, 2024 at 10:37 AM Melanie Plageman
> wrote:
> > On a related note, the other day I noticed another negative effect
> > caused in part by SKIP_PAGES_THRESHOLD. SKIP_PAGES_THRESHOLD interacts
>
On Sun, Dec 15, 2024 at 4:47 PM Tomas Vondra wrote:
>
> What's happening is that if the fraction of updated rows is sufficiently
> high, the modified pages are within the SKIP_PAGES_THRESHOLD distance,
> and vacuum switches to seqscan. But with flash storage that happens to
> be harmful - I built
l under two hours. So far, the
behavior is as expected.
> On 2024-11-01 19:35:22 -0400, Melanie Plageman wrote:
> > Because we want to amortize our eager scanning across a few vacuums,
> > we cap the maximum number of successful eager scans to a percentage of
> > the total number o
On Wed, Dec 11, 2024 at 9:44 PM Richard Guo wrote:
>
> On Wed, Dec 11, 2024 at 11:27 AM Richard Guo wrote:
>
> > Maybe I should update the test case introduced in 5668a857d to this
> > one.
>
> Done.
Great, thanks. I think the new example is more clear.
- Melanie
On Tue, Dec 3, 2024 at 3:56 AM Richard Guo wrote:
>
> I ran into $subject and it can be reproduced with the query below.
>
> create temp table tbl_rs(a int, b int);
> insert into tbl_rs select i, i from generate_series(1,10)i;
> analyze tbl_rs;
>
> set enable_nestloop to off;
> set enable_hashagg
ges newly set all-visible, of which 2 set
all-frozen. 0 all-visible pages newly set all-frozen.
insert into foo select generate_series(1,500), 1;
vacuum (verbose, freeze) foo;
--visibility map: 3 pages newly set all-visible, of which 3 set
all-frozen. 2 all-visible pages newly set all-frozen.
- M
On Thu, Dec 5, 2024 at 5:12 PM Thomas Munro wrote:
>
> Having learned some things about gettext based on clues[1] from Peter
> E, I decided to see what it would take to expunge all (long long) and
> similar casts now that we're using the standard types with system
> support.
>
> The short version
uum_vacuum_insert_threshold=1000;"
pg_ctl restart
psql -c "CREATE TABLE history( id BIGINT PRIMARY KEY GENERATED BY
DEFAULT AS IDENTITY, client_id INT NOT NULL, mtime TIMESTAMPTZ DEFAULT
NOW(), data TEXT);"
pgbench \
--random-seed=0 \
--no-vacuum \
-M prepared \
-c 8 \
-j 8 \
-t
On Wed, Sep 11, 2024 at 7:19 AM Nazir Bilal Yavuz wrote:
>
> Currently, in the pg_stat_io view, IOs are counted as blocks. However, there
> are two issues with this approach:
>
> 1- The actual number of IO requests to the kernel is lower because IO
> requests can be merged before sending the fin
On Tue, Nov 26, 2024 at 1:55 PM Masahiko Sawada wrote:
>
> Just to be clear, do users want the number of updated VM bits or the
> number of pages whose visibility information is updated? For example,
>
> > visibility map: 5 pages set all-visible, 4 pages set all-frozen.
>
> IIUC the above log can
Thanks for the review, Nitin! Attached v3 addresses your review feedback.
On Sat, Nov 2, 2024 at 7:05 AM Nitin Jadhav
wrote:
>
> 1.
> > + BlockNumber vm_page_freezes;/* # pages newly set all-frozen in VM */
> > + BlockNumber vm_page_visibles; /* # pages newly set all-visible in the
> >
On Fri, Nov 1, 2024 at 5:39 PM Masahiko Sawada wrote:
>
> I think we agreed with what the patches proposed by Melanie do, so
> let's focus on these patches on this thread. We can add other
> information later if we need.
Thanks for the feedback and input.
So, currently what I have is a line for u
Thanks for the review!
On Thu, Oct 31, 2024 at 2:13 PM Masahiko Sawada wrote:
>
>
> Some small suggestions:
>
> + vmbits = visibilitymap_set(vacrel->rel, blkno, buf,
> + InvalidXLogRecPtr,
> + vmbuffer, InvalidTra
On Thu, Oct 31, 2024 at 11:42 AM Stepan Neretin wrote:
>
> Hi there, hackers! How about trying out an idea to add an analog to save
> memory in WAL files for deleting records, similar to multi-insert
> optimization? This patch is trying to do just that.
Hi,
Thanks for the patch! Could you expla
On Thu, Oct 31, 2024 at 11:56 AM Alastair Turner wrote:
>
> For user consumption, to reduce the number of puzzled questions, I'd suggest
> adding a line to the log output of the form
>
> visibility map: %u pages set all frozen, up to %u may have been removed from
> the table
>
> rather than appe
On Thu, Oct 31, 2024 at 11:15 AM Peter Geoghegan wrote:
>
> On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman
> wrote:
> > It seems a better solution would be to find a way to document it or
> > phrase it clearly in the log. It is true that these pages were set
> >
Thanks for taking a look, Alastair!
On Thu, Oct 31, 2024 at 5:47 AM Alastair Turner wrote:
>
> The values returned in a case pages are removed (cases where the empty pages
> are at the end of the table) are a bit confusing.
>
> In an example similar to yours, but with a normal vacuum operation,
Vacuum currently counts and logs the number of pages of a relation
with newly frozen tuples. It does not count the number of pages newly
set all-frozen in the visibility map.
The number of pages set all-frozen in the visibility map by a given
vacuum can be useful when analyzing which normal vacuum
On Sat, Oct 26, 2024 at 12:17 AM Dilip Kumar wrote:
>
> On Fri, Oct 25, 2024 at 10:07 PM Melanie Plageman
> wrote:
>>
>> On Fri, Oct 25, 2024 at 10:29 AM Melanie Plageman
>> wrote:
>> >
>> > Tom suggested off-list that if rs_cindex can't be ze
On Fri, Oct 25, 2024 at 10:29 AM Melanie Plageman
wrote:
>
> Tom suggested off-list that if rs_cindex can't be zero, then it should
> be unsigned. I checked the other scan types using the
> HeapScanDescData, and it seems none of them use values of rs_cindex or
> rs_ntuples <
ething similar to this in attached v2.
> Again, I'm not clear under what circumstances will relallvisible > relpages?
I think this is mostly if someone manually updated the relation stats,
so we clamp it for safety.
- Melanie
From c2e29150e923f9782ce24a7a4e7d6f2d7445b543 Mon Sep 17 00:00:00 20
On Thu, Oct 24, 2024 at 9:40 AM Melanie Plageman
wrote:
>
> On Thu, Oct 24, 2024 at 12:50 AM Dilip Kumar wrote:
> >
> > On Thu, Oct 24, 2024 at 3:45 AM Melanie Plageman
> > wrote:
> >>
> >> HeapScanDescData->rs_cindex (the current index into the ar
On Fri, Oct 25, 2024 at 4:31 AM Andres Freund wrote:
>
> On 2024-10-25 04:14:03 -0400, Andres Freund wrote:
> > On 2024-10-25 08:22:42 +0300, Thomas Munro wrote:
> > > I wonder if this will magically fix itself when the next CI image
> > > build cron job kicks off. I have no idea what time zone t
Hi,
I know in the past docs builds failing with "failed to load external
entity" have happened on macos. But, recently I've noticed this
failure for docs build on CI (not on macos) -- docs build is one of
the jobs run under the "Compiler Warnings" task.
See an example of this on CI for the github
Thanks for the reply, Dilip!
On Thu, Oct 24, 2024 at 12:50 AM Dilip Kumar wrote:
>
> On Thu, Oct 24, 2024 at 3:45 AM Melanie Plageman
> wrote:
>>
>> HeapScanDescData->rs_cindex (the current index into the array of
>> visible tuples stored in the heap scan descr
Hi,
HeapScanDescData->rs_cindex (the current index into the array of
visible tuples stored in the heap scan descriptor) is used for
multiple scan types, but for bitmap heap scans, AFAICT, it should
never be < 0.
As such, I find this test in heapam_scan_bitmap_next_tuple() pretty confusing.
if (
On Wed, Oct 23, 2024 at 4:29 PM Andrey M. Borodin wrote:
>
> > On 23 Oct 2024, at 20:57, Andrey M. Borodin wrote:
> >
> > I'll think how to restructure flow there...
>
> OK, I've understood how it should be structured. PFA v5. Sorry for the noise.
I think this would be a bit nicer:
while (Buffe
On Tue, Oct 22, 2024 at 3:12 PM Melanie Plageman
wrote:
>
> The attached patch does this.
I realized that I broke relation_statistics_update(). Attached v2 is fixed.
> I've estimated the unfrozen percentage of the table by adding a new
> field to pg_class, relallfrozen, which
On Wed, Oct 23, 2024 at 9:32 AM Andrey M. Borodin wrote:
>
> > On 22 Oct 2024, at 16:42, Melanie Plageman
> > wrote:
> >
> > Ah, right, the callback might return InvalidBlockNumber far before
> > we've actually read (and vacuumed) the blocks it is specify
On Tue, Oct 22, 2024 at 3:21 PM David Rowley wrote:
>
> On Wed, 23 Oct 2024 at 02:08, Melanie Plageman
> wrote:
> > However, it seems like there should be a way to force an index-only
> > scan even if it is not the cheapest path. Perhaps I only think this as
> >
Hi,
Because of the way autovacuum_vacuum_[insert]_scale_factor works,
autovacuums trigger less frequently as the relation gets larger.
See this math in relation_needs_vacanalyze:
vacinsthresh = (float4) vac_ins_base_thresh + vac_ins_scale_factor * reltuples;
For an insert-only table, nearly all
On Tue, Oct 22, 2024 at 2:30 AM Andrey M. Borodin wrote:
>
> > On 22 Oct 2024, at 00:05, Melanie Plageman
> > wrote:
> >
> > I was suggesting you call RelationGetNumberOfBlocks() once
> > current_block == last_exclusive in the callback itself.
>
> Consi
On Mon, Oct 21, 2024 at 9:32 PM David Rowley wrote:
>
> There's nothing new about Index Only Scans being disabled by
> enable_indexscan. Index Only Scan is chosen with your test case as all
> possible Paths are disabled and IOS is the cheapest of all Paths.
Ah, I see! Sorry, I didn't think to com
I was surprised today when I saw that with
enable_indexscan=off
enable_indexonlyscan=on
EXPLAIN prints that the index only scan is disabled:
QUERY PLAN
---
Index Only Scan using history_pkey on history
Disabled: true
I wasn't sure
On Mon, Oct 21, 2024 at 4:49 PM Andrei Borodin wrote:
>
> 21.10.2024, 22:34, "Melanie Plageman" :
>
> The whole point of the read stream callback provided by the caller is
> that the logic to get the next block should be there
>
> We must get number of blocks
On Mon, Oct 21, 2024 at 3:34 PM Melanie Plageman
wrote:
>
> For the outer loop, I feel like we have options. For example, maybe
> the read stream callback can call RelationGetNumberOfBlocks(). I mean
> maybe we don't want to have to take a relation extension lock in a
> ca
On Sun, Oct 20, 2024 at 10:19 AM Andrey M. Borodin wrote:
>
>
>
> > On 20 Oct 2024, at 15:16, Junwang Zhao wrote:
> >
> > I'm not sure if I did not express myself correctly, I didn't mean to
> > restart the stream,
> > I mean we can create a new stream for each outer loop, I attached a
> > refact
On Tue, Oct 8, 2024 at 4:56 PM Thomas Munro wrote:
>
> Just by the way, you can't use anonymous structs or unions in C99
> (that was added to C11), but most compilers accept them silently
> unless you use eg -std=c99. Some buildfarm animal or other would
> bleat about that (ask me how I know), bu
On Wed, Jun 19, 2024 at 2:13 PM Melanie Plageman
wrote:
>
> On Wed, Jun 19, 2024 at 12:38 PM Tomas Vondra
> wrote:
>
> > > + * XXX I don't understand why we should have this special node if we
> > > + * don't have special nodes for other scan types.
>
On Fri, Sep 27, 2024 at 2:16 PM Masahiko Sawada wrote:
>
> Hi,
>
> On Thu, Sep 5, 2024 at 2:01 PM Alena Rybakina
> wrote:
> >
> > Hi! Thank you for your review!
> >
> > On 05.09.2024 15:47, jian he wrote:
> >
> > On Thu, Sep 5, 2024 at 1:23 AM Alena Rybakina
> > wrote:
> >
> > Hi, all!
> >
> >
On Mon, Aug 26, 2024 at 10:49 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Wed, Jun 19, 2024 at 2:21 PM Melanie Plageman
> > wrote:
> >> If we want to make it possible to use no tools and only manually grep
> >> for struct members, that means we
On Fri, Aug 9, 2024 at 1:03 PM Tomas Vondra wrote:
>
> On 8/9/24 17:48, Melanie Plageman wrote:
> > On Fri, Aug 9, 2024 at 9:15 AM Melanie Plageman
> > wrote:
> >>
> >> On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
> >>>
> >>
On Fri, Aug 9, 2024 at 9:15 AM Melanie Plageman
wrote:
>
> On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
> >
> > I suggest we do the simplest and most obvious algorithm possible, at
> > least for now. Focusing on this part seems like a distraction from the
> &g
On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
>
>
>
> On 8/9/24 03:02, Melanie Plageman wrote:
> > On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> >> each seconds. And we want to allow merging stuff nicely. The smallest
> >> merges we could do is 1
On Thu, Aug 8, 2024 at 9:02 PM Melanie Plageman
wrote:
>
> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> >
> > Maybe it'd be good to approach this from the opposite direction, say
> > what "accuracy guarantees" we want to provide, and then design
On Thu, Aug 8, 2024 at 3:00 PM Robert Haas wrote:
>
> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> > A-D is already enough to cover 30h, with A-E it'd be ~300h. Do we need
> > (or want) to keep a longer history?
>
> I think there is a difference of opinion about this between Melanie
> and
On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
>
> On 8/7/24 21:39, Melanie Plageman wrote:
> > On Wed, Aug 7, 2024 at 1:06 PM Robert Haas wrote:
> >>
> >> As I mentioned to you off-list, I feel like this needs some sort of
> >> recency bias.
On Wed, Aug 7, 2024 at 1:06 PM Robert Haas wrote:
>
> As I mentioned to you off-list, I feel like this needs some sort of
> recency bias. Certainly vacuum, and really almost any conceivable user
> of this facility, is going to care more about accurate answers for new
> data than for old data. If t
M. Borodin wrote:
>
> > On 1 Aug 2024, at 05:44, Melanie Plageman wrote:
> >
> > On Sat, Jul 6, 2024 at 1:36 PM Andrey M. Borodin
> > wrote:
> >>
> >> PgStartLSN = GetXLogInsertRecPtr();
> >> Should this be kind of RecoveryEndPtr? How i
On Fri, Aug 2, 2024 at 4:26 PM Tom Lane wrote:
>
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164
>
> As usual, please send corrections/comments by Sunday.
For the "Prevent infinite loop in VACUUM" item, I noticed two things
1)
a relic of my
old design. Even without your point about cache locality, the code is
much harder to understand with the backwards looping. I've changed the
array to fill forwards and be accessed with forward loops.
> > On 27 Jun 2024, at 07:18, Melanie Plageman
> > wrote:
> >
On Wed, Jul 31, 2024 at 4:38 PM Peter Geoghegan wrote:
>
> On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
> wrote:
> > In back branches starting with 14, failing to remove tuples older than
> > OldestXmin during pruning caused vacuum to infinitely loop in
> > lazy_sc
On Wed, Jul 24, 2024 at 3:43 AM John Naylor wrote:
>
> On Wed, Jul 24, 2024 at 5:40 AM Masahiko Sawada wrote:
>
> > Without MEMORY_CONTEXT_CHECK, if size is 16 bytes, required_size is
> > also 16 bytes as it's already 8-byte aligned and Bump_CHUNKHDRSZ is 0.
> > On the other hand with MEMORY_CONT
On Wed, Jul 24, 2024 at 8:19 AM John Naylor wrote:
>
> On Wed, Jul 24, 2024 at 2:42 PM John Naylor wrote:
> > As for lowering the limit, we've experimented with 256kB here:
> >
> > https://www.postgresql.org/message-id/canwcazzutvz3lsypauyqvzcezxz7qe+9ntnhgyzdtwxpul+...@mail.gmail.com
> >
> > As
On Mon, Jul 22, 2024 at 9:26 PM Masahiko Sawada wrote:
>
> + CREATE TABLE ${table1}(col1 int)
> + WITH (autovacuum_enabled=false, fillfactor=10);
> + INSERT INTO $table1 VALUES(7);
> + INSERT INTO $table1 SELECT generate_series(1, $nrows) % 3;
> + CREATE INDEX on ${table1}(col1);
> +
On Mon, Jul 22, 2024 at 10:54 PM Masahiko Sawada wrote:
>
> On Mon, Jul 22, 2024 at 6:26 PM Melanie Plageman
> wrote:
> >
> > On Mon, Jul 22, 2024 at 6:36 PM Tom Lane wrote:
> > >
> > > Melanie Plageman writes:
> > > > We've only run
1 - 100 of 766 matches
Mail list logo
