[COMMITTERS] pgsql: Add comment on why pulling data from a "name" index column can't

2011-10-11 Thread Tom Lane
Add comment on why pulling data from a "name" index column can't crash. It's been bothering me for several days that pretending that the cstring data stored in a btree name_ops column is really a "name" Datum could lead to reading past the end of memory. However, given the current memory layout u

[COMMITTERS] pgsql: Generate index-only scan tuple descriptor from the plan node's i

2011-10-11 Thread Tom Lane
Generate index-only scan tuple descriptor from the plan node's indextlist. Dept. of second thoughts: as long as we've got that tlist hanging around anyway, we can apply ExecTypeFromTL to it to get a suitable descriptor for the ScanTupleSlot. This is a nicer solution than the previous one because

[COMMITTERS] pgsql: Improve entab's Makefile install entry.

2011-10-11 Thread Bruce Momjian
Improve entab's Makefile install entry. Andrew Dunstan Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e991930e8a2394169d95e9a4c175a1fdf812ef04 Modified Files -- src/tools/entab/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) --

[COMMITTERS] pgsql: Document that not backing up postmaster.pid and postmaster.opts

2011-10-11 Thread Bruce Momjian
Document that not backing up postmaster.pid and postmaster.opts might help prevent pg_ctl from getting confused. Backpatch to 9.1. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/35db9d0ab8a81470b2be62728105cfa36e26e56c Modified Files -- doc/src/s

[COMMITTERS] pgsql: Document that not backing up postmaster.pid and postmaster.opts

2011-10-11 Thread Bruce Momjian
Document that not backing up postmaster.pid and postmaster.opts might help prevent pg_ctl from getting confused. Backpatch to 9.1. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/47cacfc0f171c7794a8a953e4676db60e1fb261c Modified Files -- doc/src/sgml/bac

Re: [COMMITTERS] pgsql: Consider index-only scans even when there is no matching qual or

2011-10-11 Thread Thom Brown
On 11 October 2011 21:45, Tom Lane wrote: > Thom Brown writes: >> So an index-only scan is 30 times slower in this particular test case. > > Don't see why you'd find that unexpected.  If you have to visit all the > rows, a seqscan is usually going to be the best way.  An indexscan only > has a ch

Re: [COMMITTERS] pgsql: Consider index-only scans even when there is no matching qual or

2011-10-11 Thread Tom Lane
Thom Brown writes: > So an index-only scan is 30 times slower in this particular test case. Don't see why you'd find that unexpected. If you have to visit all the rows, a seqscan is usually going to be the best way. An indexscan only has a chance of winning when the index is much smaller than t

Re: [COMMITTERS] pgsql: Consider index-only scans even when there is no matching qual or

2011-10-11 Thread Thom Brown
On 11 October 2011 20:11, Tom Lane wrote: > Bruce Momjian writes: >> Tom Lane wrote: >>> Consider index-only scans even when there is no matching qual or ORDER BY. >>> >>> By popular demand. > >> Is this the COUNT(*) optimization? > > Yeah, among other cases. This is unexpected: test=# explain

Re: [COMMITTERS] pgsql: Consider index-only scans even when there is no matching qual or

2011-10-11 Thread Tom Lane
Bruce Momjian writes: > Tom Lane wrote: >> Consider index-only scans even when there is no matching qual or ORDER BY. >> >> By popular demand. > Is this the COUNT(*) optimization? Yeah, among other cases. regards, tom lane -- Sent via pgsql-committers mailing list (pg

Re: [COMMITTERS] pgsql: Consider index-only scans even when there is no matching qual or

2011-10-11 Thread Bruce Momjian
Tom Lane wrote: > Consider index-only scans even when there is no matching qual or ORDER BY. > > By popular demand. Is this the COUNT(*) optimization? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everyt

[COMMITTERS] pgsql: Consider index-only scans even when there is no matching qual or

2011-10-11 Thread Tom Lane
Consider index-only scans even when there is no matching qual or ORDER BY. By popular demand. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/600d3206d1b3f8b540397b79905486a536ac7f78 Modified Files -- src/backend/optimizer/path/indxpath.c | 25

[COMMITTERS] pgsql: Rearrange the implementation of index-only scans.

2011-10-11 Thread Tom Lane
Rearrange the implementation of index-only scans. This commit changes index-only scans so that data is read directly from the index tuple without first generating a faux heap tuple. The only immediate benefit is that indexes on system columns (such as OID) can be used in index-only scans, but thi

[COMMITTERS] pgsql: Replace hardcoded switch in object_exists() with a lookup table.

2011-10-11 Thread Robert Haas
Replace hardcoded switch in object_exists() with a lookup table. There's no particular advantage to this change on its face; indeed, it's possible that this might be slightly slower than the old way. But it makes this information more easily accessible to other functions, and therefore paves the w

[COMMITTERS] pgsql: Repair breakage in VirtualXactLock.

2011-10-11 Thread Robert Haas
Repair breakage in VirtualXactLock. I broke this in commit 84e37126770dd6de903dad88ce150a49b63b5ef9. Report and fix by Fujii Masao. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e76bcaba9cb330b32e9a80dfe9cd510d802121c4 Modified Files -- src/backend/st