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 keywor
On Fri, Nov 08, 2019 at 09:30:56AM +0900, Michael Paquier wrote:
> On Thu, Nov 07, 2019 at 06:01:34PM +0900, Kyotaro Horiguchi wrote:
>> Sorry, but I also vote -1 for the new function.
>
> So do I. If there are no objections, I will mark the patch as
> rejected in the CF app.
And done.
--
Michae
On Thu, Nov 07, 2019 at 06:01:34PM +0900, Kyotaro Horiguchi wrote:
> Sorry, but I also vote -1 for the new function.
So do I. If there are no objections, I will mark the patch as
rejected in the CF app.
> If they need it so frequently, a user-defined function is easily
> made up.
Yep.
--
Michae
Hello, Kimura-san.
At Thu, 07 Nov 2019 17:04:51 +0900, btkimurayuzk
wrote in
> > 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') /
> >> cur
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 th
On Wed, Oct 30, 2019 at 10:09:47AM -0400, Tom Lane wrote:
> 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)
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 suffici
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.
