Re: [HACKERS] Secondary index access optimizations - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Secondary index access optimizations
Date
Msg-id 20180301201555.lgoqtac46jpl4jm6@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Secondary index access optimizations  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: [HACKERS] Secondary index access optimizations  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
Hi,


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...

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Re: [HACKERS] plpgsql - additional extra checks
Next
From: Robert Haas
Date:
Subject: Re: Protect syscache from bloating with negative cache entries