Fix typo.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/041dceb2590081c397daeda84ff28ffc71a51fb0
Modified Files
--
src/include/storage/barrier.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Sent via pgsql-committers mailing list (pgs
Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.
This fixes bug #6242, reported by Sergey. Backpatch
Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.
This fixes bug #6242, reported by Sergey. Backpatch
Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.
This fixes bug #6242, reported by Sergey. Backpatch
Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.
This fixes bug #6242, reported by Sergey. Backpatch
Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.
This fixes bug #6242, reported by Sergey. Backpatch
Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.
This fixes bug #6242, reported by Sergey. Backpatch
2011/10/8 Tom Lane :
> Support index-only scans using the visibility map to avoid heap fetches.
>
> When a btree index contains all columns required by the query, and the
> visibility map shows that all tuples on a target heap page are
> visible-to-all, we don't need to fetch that heap page. This
On 19 July 2011 03:44, Simon Riggs wrote:
> Cascading replication feature for streaming log-based replication.
> Standby servers can now have WALSender processes, which can work with
> either WALReceiver or archive_commands to pass data. Fully updated
> docs, including new conceptual terms of send
Fix brain fade in cost estimation for index-only scans.
visibility_fraction should not be applied to regular indexscans.
Noted by Cédric Villemain.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/b324384f6bd5d661efeddb83d7f607781e96947d
Modified Files
--
Note that index-only scans can affect idx_tup_fetch.
An index-only scan that avoids heap fetches will increment idx_tup_read
but not idx_tup_fetch.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c78d8cd1464bc6b69fdc72f9ce51407c89554ece
Modified Files
--
Prevent index-only scans in stats regression test.
This bollixes the test because it's expecting to see the idx_tup_fetch
counter increase, which won't happen if heap fetches were avoided by use
of an index-only scan. Per buildfarm results.
While at it, let's just make sure that enable_seqscan a
Improve index-only scans to avoid repeated access to the index page.
We copy all the matched tuples off the page during _bt_readpage, instead of
expensively re-locking the page during each subsequent tuple fetch. This
costs a bit more local storage, but not more than 2*BLCKSZ worth, and the
reduc
13 matches
Mail list logo
