Re: Proposal : For Auto-Prewarm. - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Proposal : For Auto-Prewarm.
Date
Msg-id 1b9ae5e6-5662-0543-b747-e830d7cc7ce3@BlueTreble.com
Whole thread Raw
In response to Proposal : For Auto-Prewarm.  (Mithun Cy <mithun.cy@enterprisedb.com>)
Responses Re: Proposal : For Auto-Prewarm.  (Michael Paquier <michael.paquier@gmail.com>)
Re: Proposal : For Auto-Prewarm.  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Proposal : For Auto-Prewarm.  (Mithun Cy <mithun.cy@enterprisedb.com>)
List pgsql-hackers
On 10/27/16 6:39 AM, Mithun Cy wrote:
> # pg_autoprewarm.

IMO it would be better to add this functionality to pg_prewarm instead 
of creating another contrib module. That would reduce confusion and 
reduce the amount of code necessary.

+    cmp_member_elem(database);
+    cmp_member_elem(spcNode);
+    cmp_member_elem(filenode);
+    cmp_member_elem(forknum);
+    cmp_member_elem(blocknum);

Presumably the first 4 numbers will vary far less than blocknum, so it's 
probably worth reversing the order here (or at least put blocknum first).

I didn't look at the two load functions since presumably they'd go 
away/change significantly if this was combined with pg_prewarm.

+    if (!block_info_array)
+        elog(ERROR, "Out of Memory!");
AFAICT this isn't necessary since palloc will error itself if it fails.

+    snprintf(transient_dump_file_path, sizeof(dump_file_path),
+             "%s.save.tmp", DEFAULT_DUMP_FILENAME);
Since there's no method to change DEFAULT_DUMP_FILENAME, I would call it 
what it is: DUMP_FILENAME.

Also, maybe worth an assert to make sure there was enough room for the 
complete filename. That'd need to be a real check if this was 
configurable anyway.

+    if (!avoid_dumping)
+        dump_now();
Perhaps that check should be moved into dump_now() itself...
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Improving RLS planning
Next
From: Robert Haas
Date:
Subject: Re: condition variables