On Fri, Apr 24, 2020 at 2:33 PM Stephen Frost wrote:
> Greetings,
>
> * Jeff Janes (jeff.ja...@gmail.com) wrote:
> > In order to read 1409985 / 12839 = 109 rows per buffer page, the table
> must
> > be extraordinarily well clustered on this index. That degree of
> clustering
> > is going to stea
Stephen Frost writes:
> Turns out to be because what was provided wasn't actually what was being
> used- there's a domain in there and that seems to gum up the works and
> make it so we don't consider the partial index as being something we can
> use (see the discussion at the end of the other sub
Greetings,
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> In order to read 1409985 / 12839 = 109 rows per buffer page, the table must
> be extraordinarily well clustered on this index. That degree of clustering
> is going to steal much of the thunder from the index-only scan. But in my
> hands, it
On Thu, Apr 23, 2020 at 7:36 AM Arcadio Ortega Reinoso <
arcadio.ort...@gmail.com> wrote:
> explain (analyze, buffers, format text) select * from entidad where
> cod_tabla = 4
>
>
> Index Scan using idx_tabla_entidad on entidad (cost=0.56..51121.41
> rows=1405216 width=20) (actual time=0.037..242.
> If you're using SSD storage, or if the DB is small compared with
> shared_buffers or RAM, then random_page_cost should be closer to
> seq_page_cost.
I don't *think* we are using SSDs but I'll need to confirm that though.
> How large are the indexes? problem_id_idx1 ?
Using the query from he
