On Wed, Sep 08, 2021 at 10:06:25AM -0500, Jaime Casanova wrote:
> This doesn't apply anymore because of c6fc50c, can you resubmit a new
> patch?
Activity has stalled here, so I have marked the entry as RwF in the CF
app.
--
Michael
signature.asc
Description: PGP signature
On Fri, Feb 19, 2021 at 12:06:12PM +1000, Denis Smirnov wrote:
> Thanks for your review, Heikki.
>
> I have made the changes you have requested.
>
> 1. All modifications interconnected with column projection were reverted
> (they should be added in https://commitfest.postgresql.org/31/2922 if
Denis:
Thanks for considering my suggestion.
For #1, I didn't take your example into account. Thanks for pointing that
out.
Cheers
On Thu, Feb 18, 2021 at 11:59 PM Denis Smirnov wrote:
> Hello, Zhihong.
>
> Thanks for your comments.
>
> 1. I am afraid that an equivalence of "floor(val +
Hello, Zhihong.
Thanks for your comments.
1. I am afraid that an equivalence of "floor(val + 0.5)" to "cell(val)" is
incorrect: "floor(2.1 + 0.5)" returns 2 while "cell(2.1)" returns 3. We can’t
use such replacement, as you have suggested.
2. >> For compare_rows(), it seems the computation
Hi,
+ *totalrows = floor((liverows / bs.m) * totalblocks + 0.5);
Is the above equivalent to:
+ *totalrows = ceil((liverows / bs.m) * totalblocks);
For compare_rows(), it seems the computation of oa and ob can be delayed to
when ba == bb (after the first two if statements).
Cheers
Thanks for your review, Heikki.
I have made the changes you have requested.
1. All modifications interconnected with column projection were reverted (they
should be added in https://commitfest.postgresql.org/31/2922 if the current
patch would be merged one day).
2. I have returned
On 30/12/2020 11:12, Denis Smirnov wrote:
But why do you pass int natts and VacAttrStats **stats to
acquire_sample_rows()? Is it of any use? It seems to break
abstraction too.
Yes, it is really a kluge that should be discussed. The main problem
is that we don’t pass projection information to
> But why do you pass int natts and VacAttrStats **stats to
> acquire_sample_rows()? Is it of any use? It seems to break abstraction too.
Yes, it is really a kluge that should be discussed. The main problem is that we
don’t pass projection information to analyze scan (analyze begin scan
> 8 дек. 2020 г., в 16:44, Denis Smirnov написал(а):
>
> Andrey, thanks for your feedback!
>
> I agree that AMs with fix sized blocks can have much alike code in
> acquire_sample_rows() (though it is not a rule). But there are several points
> about current master sampling.
>
> * It is
Andrey, thanks for your feedback!
I agree that AMs with fix sized blocks can have much alike code in
acquire_sample_rows() (though it is not a rule). But there are several points
about current master sampling.
* It is not perfect - AM developers may want to improve it with other sampling
Hi Denis!
> 7 дек. 2020 г., в 18:23, Смирнов Денис написал(а):
>
> I suggest a refactoring of analyze AM API as it is too much heap specific at
> the moment. The problem was inspired by Greenplum’s analyze improvement for
> append-optimized row and column AM with variable size compressed
It seems that my mailing client set wrong MIME types for attached patch and it
was filtered by the web archive. So I attach the patch again for the web
archive.
diff --git a/contrib/file_fdw/file_fdw.c b/contrib/file_fdw/file_fdw.c
index 9863e32748..3cdb839489 100644
---
Hello all!I suggest a refactoring of analyze AM API as it is too much heap specific at the moment. The problem was inspired by Greenplum’s analyze improvement for append-optimized row and column AM with variable size compressed blocks.Currently we do analyze in two steps.1. Sample fix size blocks
13 matches
Mail list logo
