Re: [HACKERS] Secondary index access optimizations

From: Andres Freund <andres(at)anarazel(dot)de>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [HACKERS] Secondary index access optimizations
Date: 2018-03-01 20:15:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


This patch seems like quite a good improvement. One thing I've not
really looked at but am slightly concerned in passing: Are there cases
where we now would do a lot of predicate pruning work even though the
overhead of just evaluating the qual is trivial, e.g. because there's
only one row due to a pkey? The predtest code is many things but
lightning fast is not one of them. Obviously that won't matter for
analytics queries, but I could see it hurt in OLTPish workloads...


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-03-01 20:19:26 Re: Protect syscache from bloating with negative cache entries
Previous Message David Steele 2018-03-01 20:14:41 Re: Re: [HACKERS] plpgsql - additional extra checks