On Wed, Sep 28, 2016 at 10:48 AM, Robert Haas wrote:
> On Sun, Sep 25, 2016 at 3:28 PM, Tomas Vondra
> wrote:
> > Sure, that would be useful.
> >
> > I think it would be useful to make repository of such data sets, so that
> > patch authors & reviewers can get a reasonable collection of data set
On Wed, Sep 28, 2016 at 2:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 22, 2016 at 1:37 PM, Tom Lane wrote:
>>> OK, I'll think about how to do that more efficiently. The smaller
>>> incremental improvement isn't surprising, because in this example the
>>> index would still be 90-
Robert Haas writes:
> On Thu, Sep 22, 2016 at 1:37 PM, Tom Lane wrote:
>> OK, I'll think about how to do that more efficiently. The smaller
>> incremental improvement isn't surprising, because in this example the
>> index would still be 90-something MB if it had no free space at all,
>> so there
On Thu, Sep 22, 2016 at 1:37 PM, Tom Lane wrote:
> OK, I'll think about how to do that more efficiently. The smaller
> incremental improvement isn't surprising, because in this example the
> index would still be 90-something MB if it had no free space at all,
> so there's going to be decreasing r
On Sun, Sep 25, 2016 at 3:28 PM, Tomas Vondra
wrote:
> Sure, that would be useful.
>
> I think it would be useful to make repository of such data sets, so that
> patch authors & reviewers can get a reasonable collection of data sets if
> needed, instead of scrambling every time. Opinions?
In theo
On 09/25/2016 08:33 PM, Oleg Bartunov wrote:
On Sat, Sep 24, 2016 at 11:32 PM, Tomas Vondra
wrote:
On 09/22/2016 07:37 PM, Tom Lane wrote:
Tomas Vondra writes:
... I've tried increasing the cache size to 768
entries, with vast majority of them (~600) allocated to leaf pages.
Sadly, this se
On Sat, Sep 24, 2016 at 11:32 PM, Tomas Vondra
wrote:
> On 09/22/2016 07:37 PM, Tom Lane wrote:
>>
>> Tomas Vondra writes:
>>
>>> ... I've tried increasing the cache size to 768
>>> entries, with vast majority of them (~600) allocated to leaf pages.
>>> Sadly, this seems to only increase the CREA
On 09/22/2016 07:37 PM, Tom Lane wrote:
Tomas Vondra writes:
... I've tried increasing the cache size to 768
entries, with vast majority of them (~600) allocated to leaf pages.
Sadly, this seems to only increase the CREATE INDEX duration a bit,
without making the index significantly smaller (s
Tomas Vondra writes:
>> On 08/25/2016 01:45 AM, Tom Lane wrote:
>>> I'll put this in the commitfest queue. It could use review from
>>> someone with the time and motivation to do performance
>>> testing/tuning.
> I've been toying with this patch a bit today, particularly looking at
> (1) sizing
On 08/25/2016 03:26 AM, Tomas Vondra wrote:
On 08/25/2016 01:45 AM, Tom Lane wrote:
Over in the thread about the SP-GiST inet opclass, I threatened to
post a patch like this, and here it is.
The basic idea is to track more than just the very latest page
we've used in each of the page categori
On 08/25/2016 01:45 AM, Tom Lane wrote:
Over in the thread about the SP-GiST inet opclass, I threatened to post
a patch like this, and here it is.
The basic idea is to track more than just the very latest page we've used
in each of the page categories that SP-GiST works with. I started with a
Over in the thread about the SP-GiST inet opclass, I threatened to post
a patch like this, and here it is.
The basic idea is to track more than just the very latest page we've used
in each of the page categories that SP-GiST works with. I started with an
arrangement that gave an equal number of c
12 matches
Mail list logo
