On 03/22/2018 08:51 PM, Tom Lane wrote:
> I wrote:
>> Tomas Vondra writes:
>>> The 0002 part is the main part, unifying the definition of reltuples on
>>> three main places:
>
>> On to this part ...
>
> I've pushed 0002 with several corrections: it did not seem to me that
> you'd correctly propa
I wrote:
> Tomas Vondra writes:
>> The 0002 part is the main part, unifying the definition of reltuples on
>> three main places:
> On to this part ...
I've pushed 0002 with several corrections: it did not seem to me that
you'd correctly propagated what ANALYZE is doing into CREATE INDEX or
pgsta
Tomas Vondra writes:
> 0001 fixes this by tracking the number of actually indexed rows in the
> build states, just like in the other index AMs.
> A VACUUM or ANALYZE will fix the estimate, of course, but for tables
> that are not changing very much it may take quite a while. So I think
> this is s
Hi,
So here is an updated version of the patch/fix, addressing the remaining
issues in v3 posted by Tom in November.
The 0001 part is actually a bugfix in bloom and spgist index AM, which
did something like this:
reltuples = IndexBuildHeapScan(...)
result->heap_tuples = result->index_t
On 03/05/2018 04:12 PM, David Steele wrote:
> Hi Tomas,
>
> On 1/8/18 3:28 PM, Tomas Vondra wrote:
>>
>>
>> On 01/08/2018 08:39 PM, Tom Lane wrote:
>>> Tomas Vondra writes:
As I already mentioned, Tom's updated patch is better than what I
posted initially, and I agree with his approac
Hi Tomas,
On 1/8/18 3:28 PM, Tomas Vondra wrote:
>
>
> On 01/08/2018 08:39 PM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> As I already mentioned, Tom's updated patch is better than what I
>>> posted initially, and I agree with his approach to the remaining
>>> issues he pointed out. But I some
On 01/08/2018 08:39 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> As I already mentioned, Tom's updated patch is better than what I
>> posted initially, and I agree with his approach to the remaining
>> issues he pointed out. But I somehow assumed that he's already
>> looking into that. Tom, do
Tomas Vondra writes:
> As I already mentioned, Tom's updated patch is better than what I posted
> initially, and I agree with his approach to the remaining issues he
> pointed out. But I somehow assumed that he's already looking into that.
> Tom, do you plan to look into this patch soon, or should
On 01/05/2018 05:25 AM, Stephen Frost wrote:
> Tomas,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Sun, Nov 19, 2017 at 6:40 AM, Tomas Vondra
>> wrote:
>>> Thanks for looking into this. I agree your patch is more consistent and
>>> generally cleaner.
>>
>> This is classified as
Tomas,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sun, Nov 19, 2017 at 6:40 AM, Tomas Vondra
> wrote:
> > Thanks for looking into this. I agree your patch is more consistent and
> > generally cleaner.
>
> This is classified as a bug fix, and is marked as waiting on author. I
> am
On Sun, Nov 19, 2017 at 6:40 AM, Tomas Vondra
wrote:
> Thanks for looking into this. I agree your patch is more consistent and
> generally cleaner.
This is classified as a bug fix, and is marked as waiting on author. I
am moving it to next CF as work continues.
--
Michael
BTW see bug #14863 which is related to this:
https://postgr.es/m/CAEBTBzu5j_E1K1jb9OKwTZj98MPeM7V81-vadp5adRm=nhj...@mail.gmail.com
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Tomas Vondra writes:
> On 11/02/2017 08:15 PM, Tom Lane wrote:
>> However, I'm not sure we're there yet, because there remains a fairly
>> nasty discrepancy even once we've gotten everyone onto the same page
>> about reltuples counting just live tuples: VACUUM and ANALYZE have
>> different definit
Hi,
On 11/02/2017 08:15 PM, Tom Lane wrote:
> Haribabu Kommi writes:
>> The changes are fine and now it reports proper live tuples in both
>> pg_class and stats. The other issue of continuous vacuum operation
>> leading to decrease of number of live tuples is not related to this
>> patch and that
14 matches
Mail list logo
