On 15.11.2013 12:44, Andres Freund wrote:
On 2013-11-15 12:31:54 +0200, Heikki Linnakangas wrote:
On 15.11.2013 07:47, David Rowley wrote:
On Fri, Nov 15, 2013 at 3:03 AM, Heikki Linnakangas
wrote
I think that means that we should just completely replace the list with
the hash table. The diff
On Fri, Nov 15, 2013 at 11:31 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> Thanks, committed with minor copy-editing. I dialed down the initial size
> of the hash table from 1000 to 16, that ought to be enough.
>
>
Great. Thanks for commiting.
Regards
David Rowley
> - Heikki
>
On 2013-11-15 12:31:54 +0200, Heikki Linnakangas wrote:
> On 15.11.2013 07:47, David Rowley wrote:
> >On Fri, Nov 15, 2013 at 3:03 AM, Heikki Linnakangas >>wrote
> >>
> >>I think that means that we should just completely replace the list with
> >>the hash table. The difference with a small N is lo
On 15.11.2013 07:47, David Rowley wrote:
On Fri, Nov 15, 2013 at 3:03 AM, Heikki Linnakangas
wrote
I think that means that we should just completely replace the list with
the hash table. The difference with a small N is lost in noise, so there's
no point in keeping the list as a fast path for s
On 2013-11-15 19:12:15 +1300, David Rowley wrote:
> On Fri, Nov 15, 2013 at 3:23 AM, Tom Lane wrote:
>
> > Andres Freund writes:
> > > I think it'd be a better idea to integrate the sequence caching logic
> > > into the relcache. There's a comment about it:
> > > * (We can't
> > > * rely on th
On 2013-11-15 14:22:30 +1300, David Rowley wrote:
> On Fri, Nov 15, 2013 at 3:12 AM, Andres Freund wrote:
>
> > Hi,
> >
> > On 2013-11-13 22:55:43 +1300, David Rowley wrote:
> > > Here
> > > http://www.postgresql.org/message-id/24278.1352922...@sss.pgh.pa.usthere
> > > was some talk about init_se
On Fri, Nov 15, 2013 at 3:23 AM, Tom Lane wrote:
> Andres Freund writes:
> > I think it'd be a better idea to integrate the sequence caching logic
> > into the relcache. There's a comment about it:
> > * (We can't
> > * rely on the relcache, since it's only, well, a cache, and may decide
> to
On Fri, Nov 15, 2013 at 3:03 AM, Heikki Linnakangas wrote
>
> I think that means that we should just completely replace the list with
> the hash table. The difference with a small N is lost in noise, so there's
> no point in keeping the list as a fast path for small N. That'll make the
> patch som
On Fri, Nov 15, 2013 at 3:12 AM, Andres Freund wrote:
> Hi,
>
> On 2013-11-13 22:55:43 +1300, David Rowley wrote:
> > Here
> > http://www.postgresql.org/message-id/24278.1352922...@sss.pgh.pa.usthere
> > was some talk about init_sequence being a bottleneck when many sequences
> > are used in a si
On Fri, Nov 15, 2013 at 3:03 AM, Heikki Linnakangas wrote:
> On 14.11.2013 14:38, David Rowley wrote:
>
>> I've just completed some more benchmarking of this. I didn't try dropping
>> the threshold down to 2 or 0 but I did tests at the cut over point and
>> really don't see much difference in per
On 2013-11-14 09:47:18 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-11-14 09:23:20 -0500, Tom Lane wrote:
> >> We most certainly *do* discard entries, if they're not open when a cache
> >> flush event comes along.
>
> > What I was aiming at is that we don't discard them because of a
Andres Freund writes:
> On 2013-11-14 09:23:20 -0500, Tom Lane wrote:
>> We most certainly *do* discard entries, if they're not open when a cache
>> flush event comes along.
> What I was aiming at is that we don't discard them because of a limited
> cache size. I don't think it means much that we
On 2013-11-14 09:23:20 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think it'd be a better idea to integrate the sequence caching logic
> > into the relcache. There's a comment about it:
> > * (We can't
> > * rely on the relcache, since it's only, well, a cache, and may decide to
> > *
Andres Freund writes:
> I think it'd be a better idea to integrate the sequence caching logic
> into the relcache. There's a comment about it:
> * (We can't
> * rely on the relcache, since it's only, well, a cache, and may decide to
> * discard entries.)
> but that's not really accurate anymore
Hi,
On 2013-11-13 22:55:43 +1300, David Rowley wrote:
> Here http://www.postgresql.org/message-id/24278.1352922...@sss.pgh.pa.us there
> was some talk about init_sequence being a bottleneck when many sequences
> are used in a single backend.
>
> The attached I think implements what was talked abo
On 14.11.2013 14:38, David Rowley wrote:
I've just completed some more benchmarking of this. I didn't try dropping
the threshold down to 2 or 0 but I did tests at the cut over point and
really don't see much difference in performance between the list at 32 and
the hashtable at 33 sequences. The h
On 13.11.2013 11:55, David Rowley wrote:
I thought I would post the patch early to see if this is actually wanted
before I do too much more work on it.
Seems reasonable.
My implementation maintains using the linear list for sequences up to a
defined threshold (currently 32) then it moves ever
Here http://www.postgresql.org/message-id/24278.1352922...@sss.pgh.pa.us there
was some talk about init_sequence being a bottleneck when many sequences
are used in a single backend.
The attached I think implements what was talked about in the above link
which for me seems to double the speed of a
18 matches
Mail list logo
