Hmm. I'm sorry to find that this patch is already marked as
'Return with Feedback' on the CF page around the same time when
the preveous review comment has sent. Is it somewhat crossing?
Anyway, I'll take a rain check for this.
> I have simply merged the two regtests separately into two
> origina
Thank you for the worthwhile additions.
At Tue, 16 Jul 2013 16:04:43 +0900, Satoshi Nagayasu wrote in
<51e4f08b.3030...@uptime.jp>
> > | postgres=# select * from pg_freespace_with_vminfo('t'::regclass) limit
> > | 10;
..
> I think we can simply add is_all_viible column to the existing
> pg_frees
(2013/07/09 19:55), Kyotaro HORIGUCHI wrote:
Hello, I've brought visibilitymap extentions for pg_freespacemap
and pgstattuple.
At Mon, 08 Jul 2013 16:59:05 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20130708.165905.118860769.horiguchi.kyot...@lab.ntt.co.jp>
I'll come again wi
Hello, I've brought visibilitymap extentions for pg_freespacemap
and pgstattuple.
At Mon, 08 Jul 2013 16:59:05 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20130708.165905.118860769.horiguchi.kyot...@lab.ntt.co.jp>
> I'll come again with the first implementation of it. And as for
>
On 07/08/2013 12:59 AM, Kyotaro HORIGUCHI wrote:
> I'll come again with the first implementation of it. And as for
> pg_freespacemap, I'll keep the current direction - adding column
> to present output records format of pg_freespace(). And
> documentation, if possible.
Do you think you'll be fixin
Hello,
> > - How about pageinspect?
> >
> > I proposed a simple representation format as a basis for
> > discussion. Nevertheless, the VM pages has no more structure
> > than a simple bit string. Given the VM info in pg_freespacemap,
> > I've come in doubt of the necessity of vm_page_cont
On 26 June 2013 09:09, Kyotaro HORIGUCHI wrote:
> - How about pageinspect?
>
> I proposed a simple representation format as a basis for
> discussion. Nevertheless, the VM pages has no more structure
> than a simple bit string. Given the VM info in pg_freespacemap,
> I've come in doubt of
Hello,
> I'm looking into this patch as a reviewer.
I'd appreciate your time to review.
I've had some suggestions so far,
- I should be cautious in changing existing interface.
You're right. It was somehow gone out of my mind. It might be
better to provide a separate function from the c
On Wed, Jun 19, 2013 at 11:26 PM, Satoshi Nagayasu wrote:
> - pageinspect provies several functions for debugging purpose.
> - pg_freespace provies a view for monitoring purpose.
> - pgstattuple provies several functions for collecting
> specific table/index statistics.
I think we should be car
On 20 June 2013 04:26, Satoshi Nagayasu wrote:
> I'm looking into this patch as a reviewer.
>
>
> (2013/06/19 18:03), Simon Riggs wrote:
>>
>> On 19 June 2013 09:19, Kyotaro HORIGUCHI
>> wrote:
>>
>>> It should useful in other aspects but it seems a bit complicated
>>> just to know about visibili
I'm looking into this patch as a reviewer.
(2013/06/19 18:03), Simon Riggs wrote:
On 19 June 2013 09:19, Kyotaro HORIGUCHI
wrote:
It should useful in other aspects but it seems a bit complicated
just to know about visibility bits for certain blocks.
With your current patch you can only see
On 19 June 2013 10:15, Andres Freund wrote:
> On 2013-06-19 10:03:40 +0100, Simon Riggs wrote:
>> On 19 June 2013 09:19, Kyotaro HORIGUCHI
>> wrote:
>>
>> > It should useful in other aspects but it seems a bit complicated
>> > just to know about visibility bits for certain blocks.
>>
>> With your
On 2013-06-19 10:03:40 +0100, Simon Riggs wrote:
> On 19 June 2013 09:19, Kyotaro HORIGUCHI
> wrote:
>
> > It should useful in other aspects but it seems a bit complicated
> > just to know about visibility bits for certain blocks.
>
> With your current patch you can only see the visibility info
On 19 June 2013 09:19, Kyotaro HORIGUCHI
wrote:
> It should useful in other aspects but it seems a bit complicated
> just to know about visibility bits for certain blocks.
With your current patch you can only see the visibility info for
blocks in cache, not for all blocks. So while you may think
Thank you.
> > This makes sense to me. I only lament the fact that this makes the
> > module a misnomer. Do we want to 1) rename the module (how
> > inconvenient), 2) create a separate module for this (surely not
> > warranted), or 3) accept it and move on?
Although I also feel uneasy with the
On 14 June 2013 15:22, Alvaro Herrera wrote:
> Kyotaro HORIGUCHI wrote:
>> Helle,
>>
>> I've added visibility map information to pg_freespace for my
>> utility.
>
> This makes sense to me. I only lament the fact that this makes the
> module a misnomer. Do we want to 1) rename the module (how
> i
On Fri, Jun 14, 2013 at 7:23 AM, Andres Freund wrote:
> 3). All the others seem to inflict unneccesary pain for not all that
> much gain.
+1. You might want to add a "historical note" about the name to the
pg_freespace documentation, though.
--
Peter Geoghegan
--
Sent via pgsql-hackers mail
On 2013-06-14 10:22:19 -0400, Alvaro Herrera wrote:
> Kyotaro HORIGUCHI wrote:
> > Helle,
> >
> > I've added visibility map information to pg_freespace for my
> > utility.
>
> This makes sense to me.
+1
> I only lament the fact that this makes the
> module a misnomer. Do we want to 1) rename t
Kyotaro HORIGUCHI wrote:
> Helle,
>
> I've added visibility map information to pg_freespace for my
> utility.
This makes sense to me. I only lament the fact that this makes the
module a misnomer. Do we want to 1) rename the module (how
inconvenient), 2) create a separate module for this (surely
19 matches
Mail list logo