On Wed, Mar 17, 2021 at 02:35:28PM +0900, Michael Paquier wrote:
> So we would likely want a separate function. Another possibility,
> which I find tempting, would be to push down the calculation logic
> relying on physical files down to the table AM themselves with a new
> dedicated callback (rel
‐‐‐ Original Message ‐‐‐
On Wednesday, March 17, 2021 6:35 AM, Michael Paquier
wrote:
> On Mon, Mar 15, 2021 at 03:10:59PM +0900, Michael Paquier wrote:
>
> > Anyway, as mentioned by other people upthread, I am not really
> > convinced either that we should have more flavors of siz
On Mon, Mar 15, 2021 at 03:10:59PM +0900, Michael Paquier wrote:
> Anyway, as mentioned by other people upthread, I am not really
> convinced either that we should have more flavors of size functions,
> particularly depending on the relkind as this would be confusing for
> the end-user. pg_relatio
‐‐‐ Original Message ‐‐‐
On Monday, March 15, 2021 7:10 AM, Michael Paquier wrote:
> On Wed, Feb 24, 2021 at 02:35:51PM +, gkokola...@pm.me wrote:
>
> > Now with attachment. Apologies for the chatter.
>
> The patch has no documentation for the two new functions, so it is a
> bit
On Wed, Feb 24, 2021 at 02:35:51PM +, gkokola...@pm.me wrote:
> Now with attachment. Apologies for the chatter.
The patch has no documentation for the two new functions, so it is a
bit hard to understand what is the value brought here, and what is the
goal wanted just by reading the patch, exc
‐‐‐ Original Message ‐‐‐
On Wednesday, February 24, 2021 3:34 PM, wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, February 19, 2021 4:57 PM, gkokola...@pm.me wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, February 1, 2021 1:18 PM, Masahiko Sawada sawada.m...@
‐‐‐ Original Message ‐‐‐
On Friday, February 19, 2021 4:57 PM, wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, February 1, 2021 1:18 PM, Masahiko Sawada sawada.m...@gmail.com
> wrote:
>
> > On Thu, Nov 12, 2020 at 2:54 AM Soumyadeep Chakraborty
> > soumyadeep2...@gmail.c
‐‐‐ Original Message ‐‐‐
On Monday, February 1, 2021 1:18 PM, Masahiko Sawada
wrote:
> On Thu, Nov 12, 2020 at 2:54 AM Soumyadeep Chakraborty
> soumyadeep2...@gmail.com wrote:
>
> > Hey Georgios,
> > On Tue, Nov 10, 2020 at 6:20 AM gkokola...@pm.me wrote:
> >
> > > ‐‐‐ Original
On Thu, Nov 12, 2020 at 2:54 AM Soumyadeep Chakraborty
wrote:
>
> Hey Georgios,
>
> On Tue, Nov 10, 2020 at 6:20 AM wrote:
> >
> >
> >
> >
> >
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, November 9, 2020 7:50 PM, Soumyadeep Chakraborty
> > wrote:
> >
> > > Hey Georgios,
> > >
> > >
Hey Georgios,
On Tue, Nov 10, 2020 at 6:20 AM wrote:
>
>
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, November 9, 2020 7:50 PM, Soumyadeep Chakraborty
> wrote:
>
> > Hey Georgios,
> >
> > Thanks for looking for more avenues to invoke tableAM APIS! Please find
> > my review below:
>
>
‐‐‐ Original Message ‐‐‐
On Monday, November 9, 2020 7:50 PM, Soumyadeep Chakraborty
wrote:
> Hey Georgios,
>
> Thanks for looking for more avenues to invoke tableAM APIS! Please find
> my review below:
A great review Soumyadeep, it is much appreciated.
Please remember to add your
Hey Georgios,
Thanks for looking for more avenues to invoke tableAM APIS! Please find
my review below:
On Tue, Oct 13, 2020 at 6:28 AM wrote:
1.
> /*
> - * heap size, including FSM and VM
> + * table size, including FSM and VM
> */
We should not mention FSM and VM in dbsize.c at all as thes
‐‐‐ Original Message ‐‐‐
On Thursday, September 10, 2020 12:51 PM, Daniel Gustafsson
wrote:
[snip]
> Since we have introduced the table AM api I support going throug it for all
> table accesses, so +1 on the overall idea.
>
Thank you for reviewing! Please find v2 of the patch atta
On Thu, Sep 10, 2020 at 11:51:30AM +0200, Daniel Gustafsson wrote:
> Some comments on the patch:
Extra comment for this patch: regression tests are failing.
--
Michael
signature.asc
Description: PGP signature
>> So what do you think of the patch?
>
> I would suggest to keep the original logic unless there is a bug.
IIUC, the premise of this path submission is that this codepath is in fact
buggy as it may lead to incorrect results for non-heap relations?
Since we have introduced the table AM api I sup
On 2020-09-09 12:41 a.m., gkokola...@pm.me wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, 8 September 2020 22:26, David Zhang wrote:
I found the function "table_relation_size" is only used by buffer
manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
"RELKIND_MATVIEW", i.e.
‐‐‐ Original Message ‐‐‐
On Tuesday, 8 September 2020 22:26, David Zhang wrote:
>
>
> I found the function "table_relation_size" is only used by buffer
> manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
> "RELKIND_MATVIEW", i.e.
>
> case RELKIND_RELATION:
> c
‐‐‐ Original Message ‐‐‐
On Tuesday, 8 September 2020 16:49, John Naylor
wrote:
> On Thu, Aug 27, 2020 at 9:39 AM gkokola...@pm.me wrote:
>
> > Hi all,
> > this minor patch is attempting to force the use of the tableam api in
> > dbsize where ever it is required.
> > Apparently so
I found the function "table_relation_size" is only used by buffer
manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
"RELKIND_MATVIEW", i.e.
case RELKIND_RELATION:
case RELKIND_TOASTVALUE:
case RELKIND_MATVIEW:
{
/*
*
On Thu, Aug 27, 2020 at 9:39 AM wrote:
>
> Hi all,
>
> this minor patch is attempting to force the use of the tableam api in dbsize
> where ever it is required.
>
> Apparently something similar was introduced for toast relations only.
> Intuitively it seems that the distinction between a table a
Hi all,
this minor patch is attempting to force the use of the tableam api in dbsize
where ever it is required.
Apparently something similar was introduced for toast relations only.
Intuitively it seems that the distinction between a table and a toast table is
not needed. This patch treats tab
21 matches
Mail list logo
