Re: [PERFORM] Index scan cost calculation

2015-12-03 Thread Glyn Astill
> From: Jim Nasby <jim.na...@bluetreble.com> >To: Jeff Janes <jeff.ja...@gmail.com>; Glyn Astill <glynast...@yahoo.co.uk> >Cc: Pgsql-performance <pgsql-performance@postgresql.org> >Sent: Wednesday, 2 December 2015, 22:32 >Subject: Re: [PERFORM] Index scan

Re: [PERFORM] Index scan cost calculation

2015-12-02 Thread Jim Nasby
On 11/30/15 5:03 PM, Jeff Janes wrote: It thinks the combination of (show, type, best, block) is enough to get down to a single row. One index adds "flag" to that (which is not useful to the query) and the other adds "row" to that, which is useful but the planner doesn't think it is because

Re: [PERFORM] Index scan cost calculation

2015-12-01 Thread Glyn Astill
> >Clauses that can't be used in an "indexable" way are excluded from the >index selectivity, but not from the total query selectivity. > >> Or is it just likely that the selection of the new index is just by chance? > >Bingo. > Got it, thanks! Very much appreciated. Glyn -- Sent via

Re: [PERFORM] Index scan cost calculation

2015-11-30 Thread Jeff Janes
On Mon, Nov 30, 2015 at 6:03 AM, Glyn Astill wrote: > > > > > If I create the index show+best+block+row+seat then the planner appears to > favour that, and all is well. Despite the startup cost estimate being the > same, and total cost being 0.01 higher. This is

Re: [PERFORM] Index scan cost calculation

2015-11-30 Thread Glyn Astill
> From: Jeff Janes <jeff.ja...@gmail.com> > To: Glyn Astill <glynast...@yahoo.co.uk> > Cc: Pgsql-performance <pgsql-performance@postgresql.org> > Sent: Saturday, 28 November 2015, 19:25 > Subject: Re: [PERFORM] Index scan cost calculation > > &

Re: [PERFORM] Index scan cost calculation

2015-11-28 Thread Jeff Janes
On Thu, Nov 26, 2015 at 8:11 AM, Glyn Astill wrote: > Hi All, > > Using pg 9.4.5 I'm looking at a table set up by a 3rd party application and > trying to figure out why a particular index is being chosen over another for > updates/deletes. > > From what I can see the

Re: [PERFORM] Index scan cost calculation

2015-11-26 Thread Glyn Astill
- Original Message - > From: Glyn Astill > To: Pgsql-performance > Sent: Thursday, 26 November 2015, 16:11 > Subject: [PERFORM] Index scan cost calculation > > Hi All, > > Using pg 9.4.5 I'm looking at a table set up by a 3rd

Re: [PERFORM] Index scan cost calculation

2015-11-26 Thread Tom Lane
Glyn Astill writes: > Using pg 9.4.5 I'm looking at a table set up by a 3rd party application and > trying to figure out why a particular index is being chosen over another for > updates/deletes. > From what I can see the reason is that plans using either index have the

Re: [PERFORM] Index scan cost calculation

2015-11-26 Thread Glyn Astill
- Original Message - > From: Tom Lane <t...@sss.pgh.pa.us> > To: Glyn Astill <glynast...@yahoo.co.uk> > Cc: Pgsql-performance <pgsql-performance@postgresql.org> > Sent: Thursday, 26 November 2015, 16:44 > Subject: Re: [PERFORM] Index scan cost calc

Re: [PERFORM] Index scan cost calculation

2015-11-26 Thread Tom Lane
Glyn Astill writes: >> From: Tom Lane >> The problem will probably go away by itself as your table grows, but >> if you don't want to wait, you might want to reflect on which of the index >> columns might be (partially?) functionally dependent on the

Re: [PERFORM] index scan cost

2008-08-09 Thread Jeff Frost
Tom Lane wrote: Jeff Frost [EMAIL PROTECTED] writes: I have two postgresql servers. One runs 8.3.1, the other 8.3.3. On the 8.3.1 machine, the index scans are being planned extremely low cost: Index Scan using ix_email_entity_thread on email_entity (cost=0.00..4.59 rows=1

Re: [PERFORM] index scan cost

2008-07-17 Thread Jeff Frost
On Fri, 18 Jul 2008, Dennis Brakhane wrote: The fast server makes a much more accurate estimation of the number of rows to expect (4 rows are returning, 1 was estimated). The slow server estimates 1151 rows. Try running ANALYZE on the slow one You're quite right. I probably didn't mention

Re: [PERFORM] index scan cost

2008-07-17 Thread Dennis Brakhane
The fast server makes a much more accurate estimation of the number of rows to expect (4 rows are returning, 1 was estimated). The slow server estimates 1151 rows. Try running ANALYZE on the slow one -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to

Re: [PERFORM] index scan cost

2008-07-17 Thread Tom Lane
Jeff Frost [EMAIL PROTECTED] writes: I have two postgresql servers. One runs 8.3.1, the other 8.3.3. On the 8.3.1 machine, the index scans are being planned extremely low cost: Index Scan using ix_email_entity_thread on email_entity (cost=0.00..4.59 rows=1 width=1031) (actual