> 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
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
>
>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
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
> 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
>
>
&
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
- 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
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
- 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
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
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
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
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
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
14 matches
Mail list logo