On Thu, 24 Nov 2022 at 02:27, Simon Riggs wrote:
>
> On Wed, 23 Nov 2022 at 13:04, David Rowley wrote:
> > I'd rather see this solved like v4 is doing it.
>
> Please do. No further comments. Thanks for your help
Thanks. I pushed the v4 patch with some minor comment adjustments and
also renamed
On 11/23/22 14:07, David Rowley wrote:
> On Fri, 18 Nov 2022 at 03:34, Tomas Vondra
> wrote:
>> I did some simple benchmark with v2 and v3, using the attached script,
>> which essentially just builds hash index on random data, with different
>> data types and maintenance_work_mem values. And
On Wed, 23 Nov 2022 at 13:04, David Rowley wrote:
> After getting rid of the HashInsertState code and just adding bool
> sorted to _hash_doinsert() and _hash_pgaddtup(), the resulting patch
> is much more simple:
Seems good to me and I wouldn't argue with any of your comments.
> and v4
On Fri, 18 Nov 2022 at 03:34, Tomas Vondra
wrote:
> I did some simple benchmark with v2 and v3, using the attached script,
> which essentially just builds hash index on random data, with different
> data types and maintenance_work_mem values. And what I see is this
> (median of 10 runs):
> So to
On Wed, 16 Nov 2022 at 17:33, Simon Riggs wrote:
>
> Thanks for the review, apologies for the delay in acting upon your comments.
>
> My tests show the sorted and random tests are BOTH 4.6% faster with
> the v3 changes using 5-test avg, but you'll be pleased to know your
> kit is about 15.5%
Hi,
I did some simple benchmark with v2 and v3, using the attached script,
which essentially just builds hash index on random data, with different
data types and maintenance_work_mem values. And what I see is this
(median of 10 runs):
machine data type m_w_mmasterv2
On Wed, 21 Sept 2022 at 02:32, David Rowley wrote:
>
> I took this patch for a spin and saw a 2.5% performance increase using
> the random INT test that Tom posted. The index took an average of
> 7227.47 milliseconds on master and 7045.05 with the patch applied.
Thanks for the review, apologies
On Wed, Sep 21, 2022 at 12:43:15PM +0100, Simon Riggs wrote:
> Thanks for tests and review. I'm just jumping on a plane, so may not
> respond in detail until next Mon.
Okay. If you have time to address that by next CF, that would be
interesting. For now I have marked the entry as returned with
On Wed, 21 Sept 2022 at 02:32, David Rowley wrote:
>
> On Tue, 2 Aug 2022 at 03:37, Simon Riggs wrote:
> > Using the above test case, I'm getting a further 4-7% improvement on
> > already committed code with the attached patch, which follows your
> > proposal.
> >
> > The patch passes info via a
On Tue, 2 Aug 2022 at 03:37, Simon Riggs wrote:
> Using the above test case, I'm getting a further 4-7% improvement on
> already committed code with the attached patch, which follows your
> proposal.
>
> The patch passes info via a state object, useful to avoid API churn in
> later patches.
Hi
>It's a shame you only see 3%, but that's still worth it.
Hi,
I ran this test here:
DROP TABLE hash_speed;
CREATE unlogged TABLE hash_speed (x integer);
INSERT INTO hash_speed SELECT random()*1000 FROM
generate_series(1,1000) x;
VACUUM
Timing is on.
CREATE INDEX ON hash_speed USING hash
On Fri, 5 Aug 2022 at 20:46, David Zhang wrote:
>
> On 2022-08-01 8:37 a.m., Simon Riggs wrote:
> > Using the above test case, I'm getting a further 4-7% improvement on
> > already committed code with the attached patch, which follows your
> > proposal.
>
> I ran two test cases: for committed
On 2022-08-01 8:37 a.m., Simon Riggs wrote:
Using the above test case, I'm getting a further 4-7% improvement on
already committed code with the attached patch, which follows your
proposal.
I ran two test cases: for committed patch `hash_sort_by_hash.v3.patch`, I can
see about 6 ~ 7%
On Fri, 29 Jul 2022 at 13:49, Simon Riggs wrote:
>
> On Thu, 28 Jul 2022 at 19:50, Tom Lane wrote:
> >
> > Simon Riggs writes:
> > > Thanks for the nudge. New version attached.
> >
> > I also see a speed improvement from this
> > ---
> > DROP TABLE IF EXISTS hash_speed;
> > CREATE unlogged
On Thu, 28 Jul 2022 at 19:50, Tom Lane wrote:
>
> Simon Riggs writes:
> > Thanks for the nudge. New version attached.
>
> I also see a speed improvement from this, so pushed (after minor comment
> editing).
Thanks
> I notice though that if I feed it random data,
>
> ---
> DROP TABLE IF EXISTS
Simon Riggs writes:
> Thanks for the nudge. New version attached.
I also see a speed improvement from this, so pushed (after minor comment
editing). I notice though that if I feed it random data,
---
DROP TABLE IF EXISTS hash_speed;
CREATE unlogged TABLE hash_speed (x integer);
INSERT INTO
On Wed, 27 Jul 2022 at 19:22, Tom Lane wrote:
>
> Simon Riggs writes:
> > [ hash_sort_by_hash.v2.patch ]
>
> The cfbot says this no longer applies --- probably sideswiped by
> Korotkov's sorting-related commits last night.
Thanks for the nudge. New version attached.
--
Simon Riggs
Simon Riggs writes:
> [ hash_sort_by_hash.v2.patch ]
The cfbot says this no longer applies --- probably sideswiped by
Korotkov's sorting-related commits last night.
regards, tom lane
On Monday, May 30, 2022 4:13 pmshiy.f...@fujitsu.com
wrote:
>
> On Tue, May 10, 2022 5:43 PM Simon Riggs
> wrote:
> >
> > On Sat, 30 Apr 2022 at 12:12, Amit Kapila
> > wrote:
> > >
> > > Few comments on the patch:
> > > 1. I think it is better to use DatumGetUInt32 to fetch the hash key
> > >
On Tue, May 10, 2022 5:43 PM Simon Riggs wrote:
>
> On Sat, 30 Apr 2022 at 12:12, Amit Kapila
> wrote:
> >
> > Few comments on the patch:
> > 1. I think it is better to use DatumGetUInt32 to fetch the hash key as
> > the nearby code is using.
> > 2. You may want to change the below comment in
On Sat, 30 Apr 2022 at 12:12, Amit Kapila wrote:
>
> Few comments on the patch:
> 1. I think it is better to use DatumGetUInt32 to fetch the hash key as
> the nearby code is using.
> 2. You may want to change the below comment in HSpool
> /*
> * We sort the hash keys based on the buckets they
On Mon, May 2, 2022 at 9:28 PM Simon Riggs wrote:
>
> On Sat, 30 Apr 2022 at 12:12, Amit Kapila wrote:
> >
> > On Tue, Apr 19, 2022 at 3:05 AM Simon Riggs
> > wrote:
> > >
> > > Hash index pages are stored in sorted order, but we don't prepare the
> > > data correctly.
> > >
> > > We sort the
On Sat, 30 Apr 2022 at 12:12, Amit Kapila wrote:
>
> On Tue, Apr 19, 2022 at 3:05 AM Simon Riggs
> wrote:
> >
> > Hash index pages are stored in sorted order, but we don't prepare the
> > data correctly.
> >
> > We sort the data as the first step of a hash index build, but we
> > forget to sort
On Tue, Apr 19, 2022 at 3:05 AM Simon Riggs
wrote:
>
> Hash index pages are stored in sorted order, but we don't prepare the
> data correctly.
>
> We sort the data as the first step of a hash index build, but we
> forget to sort the data by hash as well as by hash bucket.
>
I was looking into
24 matches
Mail list logo
