Hi Rob:
On Tue, Aug 23, 2016 at 4:52 PM, Rob Sargent wrote:
> By 'this' I was referring to the optimizations mentioned, and am wondering
> if this holds true under user load.
For that you'll have to refer to the source, or ask someone more
versed in pg source arcanes.
>
On 08/23/2016 08:34 AM, Francisco Olarte wrote:
On Tue, Aug 23, 2016 at 4:28 PM, Rob Sargent wrote:
On 08/23/2016 07:44 AM, Francisco Olarte wrote:
On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
I am just surprised by the order of magnitude in the
On Tue, Aug 23, 2016 at 4:28 PM, Rob Sargent wrote:
> On 08/23/2016 07:44 AM, Francisco Olarte wrote:
>> On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
>>> I am just surprised by the order of magnitude in the difference though. 2
>>> and 27 minutes that's
On 08/23/2016 07:44 AM, Francisco Olarte wrote:
Hi pinker:
On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
I am just surprised by the order of magnitude in the difference though. 2
and 27 minutes that's the huge difference... I did another, simplified test,
to make sure there
Hi pinker:
On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
> I am just surprised by the order of magnitude in the difference though. 2
> and 27 minutes that's the huge difference... I did another, simplified test,
> to make sure there is no duplicates and the only difference
Francisco Olarte wrote
> It's already been told that btrees work that way, if you find itstrange
> read a bit about them, this is completely normal, but ...
I am just surprised by the order of magnitude in the difference though. 2
and 27 minutes that's the huge difference...I did another,
On Fri, Aug 19, 2016 at 3:20 PM, Daniel Verite wrote:
> There's a simple technique that works on top of a Feistel network,
> called the cycle-walking cipher. Described for instance at:
> http://web.cs.ucdavis.edu/~rogaway/papers/subset.pdf
> I'm using the opportunity to
Francisco Olarte wrote:
> I think there are some pseudo-random number generators which
> can be made to work with any range, but do not recall which ones right
> now.
There's a simple technique that works on top of a Feistel network,
called the cycle-walking cipher. Described for
Daniel:
On Thu, Aug 18, 2016 at 5:24 PM, Daniel Verite wrote:
>> unless you know of an easy way to generate a random permutation on the
>> fly without using a lot of memory, I do not.
> It could be done by encrypting the stream.
> For 32 bits integers:
>
Francisco Olarte wrote:
> unless you know of an easy way to generate a random permutation on the
> fly without using a lot of memory, I do not.
It could be done by encrypting the stream.
For 32 bits integers:
https://wiki.postgresql.org/wiki/Skip32
For 64 bits integers:
Hi:
On Thu, Aug 18, 2016 at 1:32 PM, pinker wrote:
...
> create table t01 (id bigint);
> create index i01 on t01(id);
> insert into t01 SELECT s from generate_series(1,1000) as s;
>
> and random values:
> create table t02 (id bigint);
> create index i02 on t02(id);
> insert
W dniu 2016-08-18 14:19:25 użytkownik Ilya Kazakevich
napisał:
> >Thank you. So if that is the reason changing the fillfactor parameter should
> >help?
>
> Fillfactor is not about rebalancing, but about page split. If you have many
> insertions you may decrease
>Thank you. So if that is the reason changing the fillfactor parameter should
>help?
Fillfactor is not about rebalancing, but about page split. If you have many
insertions you may decrease fillfactor to minimize page splits, but I am not
sure it will help in your case. But you should try)
W dniu 2016-08-18 14:00:31 użytkownik Ilya Kazakevich
napisał:
> Hi,
>
> >What's the reason that postgres needs more index pages to store random
> >data
> >than sequential ones?
>
> I assume that is because B-Tree is self-balanced tree, so it needs to be
>
Hi,
>What's the reason that postgres needs more index pages to store random
>data
>than sequential ones?
I assume that is because B-Tree is self-balanced tree, so it needs to be
rebalanced after each insertion.
Random insertions may go to the head of index where no space left leading to
huge
Hi!
After doing a quick test:
with sequential values:
create table t01 (id bigint);
create index i01 on t01(id);
insert into t01 SELECT s from generate_series(1,1000) as s;
and random values:
create table t02 (id bigint);
create index i02 on t02(id);
insert into t02 SELECT random()*100 from
16 matches
Mail list logo