On Wed, Jun 12, 2019 at 9:14 AM Robert Haas wrote:
> On Tue, Jun 11, 2019 at 7:17 PM Andres Freund wrote:
> > Just to understand: What version are you targeting? It seems pretty
> > clearly v13 material to me?
>
> My current plan is to commit this to v13 as soon as the tree opens.
Committed.
On Tue, Jun 11, 2019 at 7:17 PM Andres Freund wrote:
> Just to understand: What version are you targeting? It seems pretty
> clearly v13 material to me?
My current plan is to commit this to v13 as soon as the tree opens.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Hi,
On 2019-06-10 15:35:18 -0400, Robert Haas wrote:
> On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
> > > Good catch, and now I notice that the callback is not called
> > > estimate_rel_size but relation_estimate_size. Updated patch attached;
> > > thanks for the review.
> >
> > The
> On 10 Jun 2019, at 21:35, Robert Haas wrote:
>
> On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
>>> Good catch, and now I notice that the callback is not called
>>> estimate_rel_size but relation_estimate_size. Updated patch attached;
>>> thanks for the review.
>>
>> The commit
On 2019-Jun-11, Robert Haas wrote:
> I may be missing something here, but I don't know what it is.
Huh, you're right, I misread the diff. Thanks for double-checking.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
> On 11 Jun 2019, at 15:17, Robert Haas wrote:
> I may be missing something here, but I don't know what it is.
After looking at it closer yesterday I think my original question came from a
misunderstanding of the codepath, so I too don’t think there is an issue here
(unless I’m also missing
On Mon, Jun 10, 2019 at 3:46 PM Alvaro Herrera wrote:
> I agree that you're just moving the code, but this seems to have been
> recently broken in 696d78469f37 -- it was correct before that (the
> heuristic for never vacuumed rels was in optimizer/plancat.c). So in
> reality the problem that
On 2019-Jun-10, Robert Haas wrote:
> On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
> > The commit message still refers to it as estimate_rel_size though. The
> > comment on
> > table_block_relation_estimate_size does too but that one might be
> > intentional.
>
> Oops. New version
On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
> > Good catch, and now I notice that the callback is not called
> > estimate_rel_size but relation_estimate_size. Updated patch attached;
> > thanks for the review.
>
> The commit message still refers to it as estimate_rel_size though. The
> On 7 Jun 2019, at 14:43, Robert Haas wrote:
> I think that's probably going in the wrong direction. It's arguable,
> of course. However, it seems to me that there's nothing heap-specific
> about the number 10. It's not computed based on the format of a heap
> page or a heap tuple. It's
On 2019-Jun-07, Robert Haas wrote:
> On Fri, Jun 7, 2019 at 8:43 AM Robert Haas wrote:
> > Good catch, and now I notice that the callback is not called
> > estimate_rel_size but relation_estimate_size. Updated patch attached;
> > thanks for the review.
>
> Let's try that one more time, and
Hi,
On 2019-06-07 08:32:37 -0400, Robert Haas wrote:
> On Thu, Jun 6, 2019 at 10:08 PM Michael Paquier wrote:
> > "allvisfrac", "pages" and "tuples" had better be documented about
> > which result they represent.
>
> A lot of the table AM stuff (and the related slot stuff) lacks
> function
On Fri, Jun 7, 2019 at 8:43 AM Robert Haas wrote:
> Good catch, and now I notice that the callback is not called
> estimate_rel_size but relation_estimate_size. Updated patch attached;
> thanks for the review.
Let's try that one more time, and this time perhaps I'll make it compile.
--
Robert
On Fri, Jun 7, 2019 at 4:11 AM Daniel Gustafsson wrote:
> Makes sense. Regarding one of the hacks:
>
> +* HACK: if the relation has never yet been vacuumed, use a minimum
> size
> +* estimate of 10 pages. The idea here is to avoid assuming a
> +* newly-created table is
On Thu, Jun 6, 2019 at 10:08 PM Michael Paquier wrote:
> Looks like a neat split.
Thanks.
> "allvisfrac", "pages" and "tuples" had better be documented about
> which result they represent.
A lot of the table AM stuff (and the related slot stuff) lacks
function header comments; I don't like
> On 6 Jun 2019, at 22:40, Robert Haas wrote:
> It looks to me as though any table AM that uses the relation forks
> supported by PostgreSQL in a more or less normal manner is likely to
> require an implementation of the relation_size callback that is
> identical to the one for heap, and an
On Thu, Jun 06, 2019 at 04:40:53PM -0400, Robert Haas wrote:
> It looks to me as though any table AM that uses the relation forks
> supported by PostgreSQL in a more or less normal manner is likely to
> require an implementation of the relation_size callback that is
> identical to the one for
Hi,
It looks to me as though any table AM that uses the relation forks
supported by PostgreSQL in a more or less normal manner is likely to
require an implementation of the relation_size callback that is
identical to the one for heap, and an implementation of the
estimate_rel_size method that is
18 matches
Mail list logo
