On Thu, Jan 25, 2018 at 5:53 PM, Abinaya k wrote:
> Thanks for your response.
>
> Hope those stats will be used by Query Planner.
>
> So, just for my understanding, if i don't return stats (returning NULL from
> index_bulk_delete and index_vacuum_cleanup functions), Query Planner will
> not consid
Thanks for your response.
Hope those stats will be used by Query Planner.
So, just for my understanding, if i don't return stats (returning NULL from
index_bulk_delete and index_vacuum_cleanup functions), Query Planner will
not consider my Index as part of Query Path, beyond that i don't expect a
On Wed, Jan 24, 2018 at 1:27 PM, Abinaya k wrote:
> Hai all,
> We are building In-memory index extension for postgres. We would
> capture table inserts, updates, deletes using triggers. During vacuum
> operation, postgres would give calls to ambulkdelete, amvacuumcleanup (as
> part of index
Hai all,
We are building In-memory index extension for postgres. We would
capture table inserts, updates, deletes using triggers. During vacuum
operation, postgres would give calls to ambulkdelete, amvacuumcleanup (as
part of index cleanup). As we handle all updates, deletes using triggers,
w
-- Forwarded message --
From: "Abinaya k"
Date: Jan 23, 2018 1:43 PM
Subject: Regarding ambulkdelete, amvacuumcleanup index methods
To:
Cc:
Hai all,
We are building In-memory index extension for postgres. We would
capture table inserts, updates, deletes usin
Hai all,
We are building In-memory index extension for postgres. We would
capture table inserts, updates, deletes using triggers. During vacuum
operation, postgres would give calls to ambulkdelete, amvacuumcleanup (as
part of index cleanup). As we handle all updates, deletes using triggers,
w
