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 th
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 + 0.5)"
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 o
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 PROGRESS_ANAL
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 relise
> 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 not
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
algor
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 block
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
--- a/contrib/file_fdw/file_
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 w
13 matches
Mail list logo
