2016-08-18 21:40 GMT+03:00 Victor Yegorov :
> Oh, that's interesting. I was under impression, that r_p_c reflects IO
> speed, like — make it smaller for SSDs.
> To make this query prefer BitmapScan, I need to bump r_p_c to 5.8. And 6.0
> makes it switch to SeqScan.
>
I was looking into different
2016-08-18 23:06 GMT+03:00 Jeff Janes :
> It does account for them, but perhaps not perfectly. See "[PERFORM]
> index fragmentation on insert-only table with non-unique column" for
> some arguments on that which might be relevant to you.
>
Thanks for pointing this out, good stuff to know.
If y
K te er Xi
Sent from Nine<http://www.9folders.com/>
From: Jim Nasby
Sent: 19-Aug-2016 03:32
To: Jeff Janes; Victor Yegorov
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Estimates on partial index
On 8/18/16 3:06 PM, Jeff Janes wrote:
> I
On 8/18/16 3:06 PM, Jeff Janes wrote:
If you can come up with a data generator which creates data that
others can use to reproduce this situation, we can then investigate it
in more detail.
BTW, the easy fix to this is most likely to create an index on due_date
WHERE is_current. Or perhaps par
On Thu, Aug 18, 2016 at 11:55 AM, Victor Yegorov wrote:
> 2016-08-18 18:59 GMT+03:00 Jeff Janes :
>>
>> Both plans touch the same pages. The index scan just touches some of
>> those pages over and over again. A large setting of
>> effective_cache_size would tell it that the page will most likely
2016-08-18 18:59 GMT+03:00 Jeff Janes :
> Both plans touch the same pages. The index scan just touches some of
> those pages over and over again. A large setting of
> effective_cache_size would tell it that the page will most likely
> still be in cache when it comes back to touch it again, meani
2016-08-18 16:56 GMT+03:00 Tom Lane :
> In that case you've got random_page_cost too far down. Values less than
> the default of 4 are generally only appropriate if the bulk of your
> database stays in RAM.
>
Oh, that's interesting. I was under impression, that r_p_c reflects IO
speed, like — ma
On Thu, Aug 18, 2016 at 6:52 AM, Victor Yegorov wrote:
> Greetings.
>
> I have a question on why planner chooses `IndexScan` for the following
> query:
>
> SELECT la.loan_id, la.due_date, la.is_current
> FROM loan_agreements la WHERE la.is_current AND '2016-08-11' >
> la.due_date;
>
...
Victor Yegorov writes:
> Settings:
> random_page_cost 2.5 ¤
> seq_page_cost1¤
> Question is â why IndexScan over partial index is estimated less than
> BitmapHeap + BitmapIndex scan. And how can I tell Planner, that IndexScan
> over 1/3 of table is not a good
Greetings.
I have a question on why planner chooses `IndexScan` for the following
query:
SELECT la.loan_id, la.due_date, la.is_current
FROM loan_agreements la WHERE la.is_current AND '2016-08-11' >
la.due_date;
Relevant (cannot post it all, sorry) table definition is:
10 matches
Mail list logo
