Re: pg_waldump and PREPARE

2019-11-19 Thread btkimurayuzk
I did not see any problems in this version of the patch. The information displayed by pg_waldump for the PREPARE record is sufficient for use. Thanks Andrey and Michael for the review! I committed the patch. Regards, Hi, There is a mistake in the comment in the definition of

Re: Allow CREATE OR REPLACE VIEW to rename the columns

2019-11-19 Thread btkimurayuzk
Barring any objection, I'm thinking to commit this patch. Regards, Build and All Test has passed . Looks good to me . Regards,

Re: Add SQL function to show total block numbers in the relation

2019-11-12 Thread btkimurayuzk
Size in block number is useless for those who doesn't understand the notion of block, or block size. Those who understands the notion should come up with the simple formula (except the annoying casts). Anyone can find the clue to the base values by searching the document in the Web with the

Re: Resume vacuum and autovacuum from interruption and cancellation

2019-11-07 Thread btkimurayuzk
+ VACOPT_RESUME = 1 << 8/* resume from the previous point */ I think this unused ENUM value is not needed. Regards, Yu Kimura

Re: Add SQL function to show total block numbers in the relation

2019-11-07 Thread btkimurayuzk
btkimurayuzk writes: I propose new simple sql query, which shows total block numbers in the relation. ... Of cource, we can know this value such as select (pg_relation_size('t') / current_setting('block_size')::bigint)::int; I don't really see why the existing solution isn't sufficient. I

Re: pgbench - extend initialization phase control

2019-11-07 Thread btkimurayuzk
2019-11-06 11:31 に Fujii Masao さんは書きました: On Wed, Nov 6, 2019 at 6:23 AM Fabien COELHO wrote: Hello, >>> - for (step = initialize_steps; *step != '\0'; step++) >>> + for (const char *step = initialize_steps; *step != '\0'; step++) > > But I still wonder why we should apply such change here.

Add SQL function to show total block numbers in the relation

2019-10-30 Thread btkimurayuzk
Hello, I propose new simple sql query, which shows total block numbers in the relation. I now reviewing this patch (https://commitfest.postgresql.org/25/2211/) and I think, it is usefull for knowing how many blocks there are in the relation to determine whether we use VACUUM RESUME or not.