On Sun, 21 Jan 2024 at 07:32, vignesh C wrote:
>
> On Wed, 2 Aug 2023 at 21:34, Tomas Vondra
> wrote:
> >
> >
> >
> > On 8/2/23 17:25, Sergey Dudoladov wrote:
> > > Hello,
> > >
> > >> Parallel version is not supported, but I think it should be possible.
> > >
> > > @Tomas are you working on thi
On Wed, 2 Aug 2023 at 21:34, Tomas Vondra wrote:
>
>
>
> On 8/2/23 17:25, Sergey Dudoladov wrote:
> > Hello,
> >
> >> Parallel version is not supported, but I think it should be possible.
> >
> > @Tomas are you working on this ? If not, I would like to give it a try.
> >
>
> Feel free to try. Just
On 8/2/23 17:25, Sergey Dudoladov wrote:
> Hello,
>
>> Parallel version is not supported, but I think it should be possible.
>
> @Tomas are you working on this ? If not, I would like to give it a try.
>
Feel free to try. Just keep it in a separate part/patch, to make it
easier to combine the
Hello,
> Parallel version is not supported, but I think it should be possible.
@Tomas are you working on this ? If not, I would like to give it a try.
> static void
> AssertCheckRanges(BrinSortState *node)
> {
> #ifdef USE_ASSERT_CHECKING
>
> #endif
> }
I guess it should not be empty at the ong
On 7/14/23 16:42, Matthias van de Meent wrote:
> On Fri, 14 Jul 2023 at 16:21, Tomas Vondra
> wrote:
>>
>>
>>
>>
>> On 7/11/23 13:20, Matthias van de Meent wrote:
>>> On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
>>> wrote:
Approximation in what sense? My understanding was we'd get a range o
On Fri, 14 Jul 2023 at 16:21, Tomas Vondra
wrote:
>
>
>
>
> On 7/11/23 13:20, Matthias van de Meent wrote:
>> On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
>> wrote:
>>> Approximation in what sense? My understanding was we'd get a range of
>>> distances that we know covers all rows in that range. So
On 7/11/23 13:20, Matthias van de Meent wrote:
> On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
> wrote:
>> On 7/10/23 18:18, Matthias van de Meent wrote:
>>> On Mon, 10 Jul 2023 at 17:09, Tomas Vondra
>>> wrote:
On 7/10/23 14:38, Matthias van de Meent wrote:
>> I haven't really thought
On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
wrote:
> On 7/10/23 18:18, Matthias van de Meent wrote:
>> On Mon, 10 Jul 2023 at 17:09, Tomas Vondra
>> wrote:
>>> On 7/10/23 14:38, Matthias van de Meent wrote:
> I haven't really thought about geometric types, just about minmax and
> minmax-mu
On 7/10/23 18:18, Matthias van de Meent wrote:
> On Mon, 10 Jul 2023 at 17:09, Tomas Vondra
> wrote:
>> On 7/10/23 14:38, Matthias van de Meent wrote:
>>> Kind of. For single-dimensional opclasses (minmax, minmax_multi) we
>>> only need to extract the normal min/max values for ASC/DESC sorts,
>
On Mon, 10 Jul 2023 at 17:09, Tomas Vondra
wrote:
> On 7/10/23 14:38, Matthias van de Meent wrote:
>> Kind of. For single-dimensional opclasses (minmax, minmax_multi) we
>> only need to extract the normal min/max values for ASC/DESC sorts,
>> which are readily available in the summary. But for mul
On Mon, 10 Jul 2023 at 13:43, Tomas Vondra
wrote:
> On 7/10/23 12:22, Matthias van de Meent wrote:
>> On Fri, 7 Jul 2023 at 20:26, Tomas Vondra
>> wrote:
>>> However, it's not quite clear to me is what you mean by the weight- and
>>> compare-operators? That is, what are
>>>
>>> - brin_minmax_mi
On 7/10/23 12:22, Matthias van de Meent wrote:
> On Fri, 7 Jul 2023 at 20:26, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> I finally had time to look at this patch again. There's a bit of bitrot,
>> so here's a rebased version (no other changes).
>
> Thanks!
>
>> On 2/27/23 16:40, Matthias van de M
On Fri, 7 Jul 2023 at 20:26, Tomas Vondra wrote:
>
> Hi,
>
> I finally had time to look at this patch again. There's a bit of bitrot,
> so here's a rebased version (no other changes).
Thanks!
> On 2/27/23 16:40, Matthias van de Meent wrote:
> > Some initial comments on 0004:
> >
> >> +/*
> >> +
Hi,
I finally had time to look at this patch again. There's a bit of bitrot,
so here's a rebased version (no other changes).
[more comments inline]
On 2/27/23 16:40, Matthias van de Meent wrote:
> Hi,
>
> On Thu, 23 Feb 2023 at 17:44, Matthias van de Meent
> wrote:
>>
>> I'll see to further re
On 2023-Feb-24, Tomas Vondra wrote:
> On 2/24/23 16:14, Alvaro Herrera wrote:
> > I think a formulation of this kind has the benefit that it works after
> > BlockNumber is enlarged to 64 bits, and doesn't have to be changed ever
> > again (assuming it is correct).
>
> Did anyone even propose doi
Hi,
On Thu, 23 Feb 2023 at 17:44, Matthias van de Meent
wrote:
>
> I'll see to further reviewing 0004 and 0005 when I have additional time.
Some initial comments on 0004:
> +/*
> + * brin_minmax_ranges
> + *Load the BRIN ranges and sort them.
> + */
> +Datum
> +brin_minmax_ranges(PG_FUN
On Fri, 24 Feb 2023, 20:14 Tomas Vondra, wrote:
>
> On 2/24/23 19:03, Matthias van de Meent wrote:
> > On Thu, 23 Feb 2023 at 19:48, Tomas Vondra
> >> Yeah, that sounds like a bug. Also a sign the tests should have some
> >> by-ref data types (presumably there are none, as that would certainly
> >
On 2/24/23 19:03, Matthias van de Meent wrote:
> On Thu, 23 Feb 2023 at 19:48, Tomas Vondra
> wrote:
>>
>> On 2/23/23 17:44, Matthias van de Meent wrote:
>>> On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
>>> wrote:
On 2/23/23 15:19, Matthias van de Meent wrote:
> Comments on 0001, m
On Thu, 23 Feb 2023 at 19:48, Tomas Vondra
wrote:
>
> On 2/23/23 17:44, Matthias van de Meent wrote:
> > On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
> > wrote:
> >>
> >> On 2/23/23 15:19, Matthias van de Meent wrote:
> >>> Comments on 0001, mostly comments and patch design:
> >
> > One more commen
On Fri, 24 Feb 2023 at 17:04, Tomas Vondra
wrote:
>
> On 2/24/23 16:14, Alvaro Herrera wrote:
> > ... if pagesPerRange is not a whole divisor of MaxBlockNumber, I think
> > this will neglect the last range in the table.
> >
>
> Why would it? Let's say BlockNumber is uint8, i.e. 255 max. And there
On 2/24/23 16:14, Alvaro Herrera wrote:
> On 2023-Feb-24, Tomas Vondra wrote:
>
>> I guess the easiest fix would be to do the arithmetic in 64 bits. That'd
>> eliminate the overflow.
>
> Yeah, that might be easy to set up. We then don't have to worry about
> it until BlockNumber is enlarged t
On 2023-Feb-24, Tomas Vondra wrote:
> I guess the easiest fix would be to do the arithmetic in 64 bits. That'd
> eliminate the overflow.
Yeah, that might be easy to set up. We then don't have to worry about
it until BlockNumber is enlarged to 64 bits ... but by that time surely
we can just grow
On 2/24/23 09:39, Alvaro Herrera wrote:
> On 2023-Feb-23, Matthias van de Meent wrote:
>
>>> + for (heapBlk = 0; heapBlk < nblocks; heapBlk += pagesPerRange)
>>
>> I am not familiar with the frequency of max-sized relations, but this
>> would go into an infinite loop for pagesPerRange values >1
On 2023-Feb-23, Matthias van de Meent wrote:
> > + for (heapBlk = 0; heapBlk < nblocks; heapBlk += pagesPerRange)
>
> I am not familiar with the frequency of max-sized relations, but this
> would go into an infinite loop for pagesPerRange values >1 for
> max-sized relations due to BlockNumber wra
On 2/23/23 17:44, Matthias van de Meent wrote:
> On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
> wrote:
>>
>> On 2/23/23 15:19, Matthias van de Meent wrote:
>>> Comments on 0001, mostly comments and patch design:
>
> One more comment:
>
+ range->min_value = bval->bv_values[0];
+ range->ma
On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
wrote:
>
> On 2/23/23 15:19, Matthias van de Meent wrote:
>> Comments on 0001, mostly comments and patch design:
One more comment:
>>> + range->min_value = bval->bv_values[0];
>>> + range->max_value = bval->bv_values[1];
This produces dangling pointers
On 2/23/23 15:19, Matthias van de Meent wrote:
> On Sat, 18 Feb 2023 at 16:55, Tomas Vondra
> wrote:
>>
>> cfbot complained there's one more place triggering a compiler warning on
>> 32-bit systems, so here's a version fixing that.
>>
>> I've also added a copy of the regression tests but using the
On Sat, 18 Feb 2023 at 16:55, Tomas Vondra
wrote:
>
> cfbot complained there's one more place triggering a compiler warning on
> 32-bit systems, so here's a version fixing that.
>
> I've also added a copy of the regression tests but using the indexam
> stats added in 0001. This is just a copy of t
On 2/18/23 19:51, Justin Pryzby wrote:
> Are (any of) these patches targetting v16 ?
>
Probably not. Maybe if there's more feedback / scrutiny, but I'm not
sure one commitfest is enough to polish the patch (especially
considering I haven't done much on the costing yet).
> typos:
> ar we - we are
Are (any of) these patches targetting v16 ?
typos:
ar we - we are?
morestly - mostly
interstect - intersect
> + * XXX We don't sort the bins, so just do binary sort. For large number of
> values
> + * this might be an issue, for small number of values a linear search is
> fine.
"binary sort" i
On Thu, Feb 16, 2023 at 03:07:59PM +0100, Tomas Vondra wrote:
> Rebased version of the patches, fixing only minor conflicts.
Per cfbot, the patch fails on 32 bit builds.
+ERROR: count mismatch: 0 != 1000
And causes warnings in mingw cross-compile.
On Sun, Oct 23, 2022 at 11:32:37PM -0500, Justi
Hi,
On 2022-11-17 00:52:35 +0100, Tomas Vondra wrote:
> Well, yeah. That's pretty much exactly what the last version of this
> patch (from October 23) does.
That version unfortunately doesn't build successfully:
https://cirrus-ci.com/task/5108789846736896
[03:02:48.641] Duplicate OIDs detected:
On 11/16/22 22:52, Greg Stark wrote:
> Fwiw tuplesort does do something like what you want for the top-k
> case. At least it used to last I looked -- not sure if it went out
> with the tapesort ...
> > For top-k it inserts new tuples into the heap data structure and then
> pops the top element out
Fwiw tuplesort does do something like what you want for the top-k
case. At least it used to last I looked -- not sure if it went out
with the tapesort ...
For top-k it inserts new tuples into the heap data structure and then
pops the top element out of the hash. That keeps a fixed number of
elemen
On 10/24/22 06:32, Justin Pryzby wrote:
> On Sat, Oct 15, 2022 at 02:33:50PM +0200, Tomas Vondra wrote:
>> Of course, if there are e.g. BTREE indexes this is going to be slower,
>> but people are unlikely to have both index types on the same column.
>
> On Sun, Oct 16, 2022 at 05:48:31PM +0200,
On 10/17/22 16:00, Matthias van de Meent wrote:
> On Mon, 17 Oct 2022 at 05:43, Tomas Vondra
> wrote:
>>
>> On 10/16/22 22:17, Matthias van de Meent wrote:
>>> On Sun, 16 Oct 2022 at 16:34, Tomas Vondra
>>> wrote:
Try to formulate the whole algorithm. Maybe I'm missing something.
T
On Mon, 17 Oct 2022 at 05:43, Tomas Vondra
wrote:
>
> On 10/16/22 22:17, Matthias van de Meent wrote:
> > On Sun, 16 Oct 2022 at 16:34, Tomas Vondra
> > wrote:
> >> Try to formulate the whole algorithm. Maybe I'm missing something.
> >>
> >> The current algorithm is something like this:
> >>
> >>
On 10/16/22 22:17, Matthias van de Meent wrote:
> First of all, it's really great to see that this is being worked on.
>
> On Sun, 16 Oct 2022 at 16:34, Tomas Vondra
> wrote:
>> Try to formulate the whole algorithm. Maybe I'm missing something.
>>
>> The current algorithm is something like this:
First of all, it's really great to see that this is being worked on.
On Sun, 16 Oct 2022 at 16:34, Tomas Vondra
wrote:
> Try to formulate the whole algorithm. Maybe I'm missing something.
>
> The current algorithm is something like this:
>
> 1. request info about ranges from the BRIN opclass
> 2.
On Sun, 16 Oct 2022 at 16:42, Tom Lane wrote:
>
> It also seems kind of unfair to decide
> that the relevant comparison point is a seqscan rather than a
> btree indexscan.
I think the comparison against full table scan seems appropriate, as
the benefit of BRIN is less space usage when compared to
On 10/16/22 16:42, Zhihong Yu wrote:
> ...
>
> I don't have good answer w.r.t. splitting the page range [0,127] now.
> Let me think more about it.
>
Sure, no problem.
> The 10 step flow (subject to changes down the road) should be either
> given in the description of the patch or, written as co
On 10/16/22 16:41, Tom Lane wrote:
> Tomas Vondra writes:
>> I forgot to mention one important issue in my list yesterday, and that's
>> memory consumption.
>
> TBH, this is all looking like vastly more complexity than benefit.
> It's going to be impossible to produce a reliable cost estimate
On Sun, Oct 16, 2022 at 7:33 AM Tomas Vondra
wrote:
>
>
> On 10/16/22 16:01, Zhihong Yu wrote:
> >
> >
> > On Sun, Oct 16, 2022 at 6:51 AM Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > wrote:
> >
> > On 10/15/22 14:33, Tomas Vondra wrote:
> > > Hi,
> > >
> > > ...
>
Tomas Vondra writes:
> I forgot to mention one important issue in my list yesterday, and that's
> memory consumption.
TBH, this is all looking like vastly more complexity than benefit.
It's going to be impossible to produce a reliable cost estimate
given all the uncertainty, and I fear that will
On 10/16/22 16:01, Zhihong Yu wrote:
>
>
> On Sun, Oct 16, 2022 at 6:51 AM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>
> On 10/15/22 14:33, Tomas Vondra wrote:
> > Hi,
> >
> > ...
> >
> > There's a bunch of issues with this initial version of the p
On 10/16/22 03:36, Zhihong Yu wrote:
>
>
> On Sat, Oct 15, 2022 at 8:23 AM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>
> On 10/15/22 15:46, Zhihong Yu wrote:
> >...
> > 8) Parallel version is not supported, but I think it shouldn't be
> > possible.
On Sun, Oct 16, 2022 at 6:51 AM Tomas Vondra
wrote:
> On 10/15/22 14:33, Tomas Vondra wrote:
> > Hi,
> >
> > ...
> >
> > There's a bunch of issues with this initial version of the patch,
> > usually described in XXX comments in the relevant places.6)
> >
> > ...
>
> I forgot to mention one import
On 10/15/22 14:33, Tomas Vondra wrote:
> Hi,
>
> ...
>
> There's a bunch of issues with this initial version of the patch,
> usually described in XXX comments in the relevant places.6)
>
> ...
I forgot to mention one important issue in my list yesterday, and that's
memory consumption. The way t
On Sat, Oct 15, 2022 at 8:23 AM Tomas Vondra
wrote:
> On 10/15/22 15:46, Zhihong Yu wrote:
> >...
> > 8) Parallel version is not supported, but I think it shouldn't be
> > possible. Just make the leader build the range info, and then let the
> > workers to acquire/sort ranges and merg
On 10/15/22 15:46, Zhihong Yu wrote:
>...
> 8) Parallel version is not supported, but I think it shouldn't be
> possible. Just make the leader build the range info, and then let the
> workers to acquire/sort ranges and merge them by Gather Merge.
> ...
> Hi,
> I am still going over the
On Sat, Oct 15, 2022 at 5:34 AM Tomas Vondra
wrote:
> Hi,
>
> There have been a couple discussions about using BRIN indexes for
> sorting - in fact this was mentioned even in the "Improving Indexing
> Performance" unconference session this year (don't remember by whom).
> But I haven't seen any p
51 matches
Mail list logo
