On Wed, Dec 2, 2015 at 8:42 PM, Bruce Momjian wrote:
> No one mentioned the random page docs so I will quote it here:
>
>
> http://www.postgresql.org/docs/9.5/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
>
> Random access to mechanical disk storage is normally m
On Mon, Nov 30, 2015 at 04:29:43PM +0900, KAWAMICHI Ryoji wrote:
>
>
> Robert Haas wrote:
> >
> > - If we're sequential scanning a small table, let's say less than 1/4
> > of shared_buffers, which is the point where synchronized scans kick
> > in, then assume the data is coming from shared_buff
Robert Haas wrote:
>
> - If we're sequential scanning a small table, let's say less than 1/4
> of shared_buffers, which is the point where synchronized scans kick
> in, then assume the data is coming from shared_buffers.
> - If we're scanning a medium-sized table, let's say less than
> effectiv
On Mon, Nov 16, 2015 at 6:50 PM, Jeff Janes wrote:
> On Mon, Nov 9, 2015 at 6:37 AM, Tom Lane wrote:
>> kawami...@tkl.iis.u-tokyo.ac.jp writes:
>>> - cost parameter calibration: random_page_cost = 92.89
>>
>> TBH, you lost me there already. I know of no hardware on which that would
>> be a
On Mon, Nov 9, 2015 at 6:37 AM, Tom Lane wrote:
> kawami...@tkl.iis.u-tokyo.ac.jp writes:
>> - cost parameter calibration: random_page_cost = 92.89
>
> TBH, you lost me there already. I know of no hardware on which that would
> be a sane depiction of reality, so I think you've probably over
On Mon, Nov 9, 2015 at 2:42 AM, Simon Riggs wrote:
> On 9 November 2015 at 10:08, wrote:
>>
>>
>> We guessed the cause of this error would be in the cost model of Postgres,
>> and investigated the source code of optimizer, and we found the cause of
>> this problem. It was in the index cost estima
wrote:
>>
>> We guessed the cause of this error would be in the cost model of Postgres,
>> and investigated the source code of optimizer, and we found the cause of
>> this problem. It was in the index cost estimation process. On scanning
>> inner table, if loop count is greater than 1, its I/O co
wrote:
>
> More knowledgeable people are sure to reply in more detail!
>
> However, they would probably appreciate it if you can run with 9.4.5
> (the latest released version). Running it with the beta of 9.5 would be
> a bonus!
>
> Note that I don't know enough to say for sure that later ve
wrote:
>>
>> - cost parameter calibration: random_page_cost = 92.89
>>
>
> This demands some explanation and raises question of value of seq_page_cost
> parameter -- I don't see anything about it your mail.
seq_page_cost was set to 1.0 (default), and I explained the reason about
random_p
kawami...@tkl.iis.u-tokyo.ac.jp writes:
> - cost parameter calibration: random_page_cost = 92.89
TBH, you lost me there already. I know of no hardware on which that would
be a sane depiction of reality, so I think you've probably overfitted the
model to some particular case it was already i
On 9 November 2015 at 10:08, wrote:
>
> We guessed the cause of this error would be in the cost model of Postgres,
> and investigated the source code of optimizer, and we found the cause of
> this problem. It was in the index cost estimation process. On scanning
> inner table, if loop count is gr
On 09/11/15 23:08, kawami...@tkl.iis.u-tokyo.ac.jp wrote:
Hi guys,
I’ve been using Postgres for research at an university,
Great!
[...]
・Postgres 9.4.1
[..]
More knowledgeable people are sure to reply in more detail!
However, they would probably appreciate it if you can run with 9.4.5
(th
On Mon, Nov 9, 2015 at 11:08 AM, wrote:
>
> - cost parameter calibration: random_page_cost = 92.89
>
This demands some explanation and raises question of value of seq_page_cost
parameter -- I don't see anything about it your mail.
--
Alex
13 matches
Mail list logo
