On 10/31/24 19:05, Andrey M. Borodin wrote:
>
>
>> On 8 Oct 2024, at 17:05, Tomas Vondra wrote:
>>
>> Here's an updated patch adding the queryid.
>
> I've took another round of looking through the patch.
> Everything I see seems correct to me. It just occurred to me that we
> will have: buffere
> On 8 Oct 2024, at 17:05, Tomas Vondra wrote:
>
> Here's an updated patch adding the queryid.
I've took another round of looking through the patch.
Everything I see seems correct to me. It just occurred to me that we will have:
buffered build, parallel build, sorting build. All 3 aiming to
On 10/8/24 04:05, Michael Paquier wrote:
> On Tue, Jul 30, 2024 at 11:05:56AM +0200, Tomas Vondra wrote:
>> I tried implementing this, see the attached 0002 patch that replaces the
>> fake LSN with an atomic counter in shared memory. It seems to work (more
>> testing needed), but I can't say I'm ve
On Tue, Jul 30, 2024 at 11:05:56AM +0200, Tomas Vondra wrote:
> I tried implementing this, see the attached 0002 patch that replaces the
> fake LSN with an atomic counter in shared memory. It seems to work (more
> testing needed), but I can't say I'm very happy with the code :-(
While scanning qui
Hi,
Here's an updated patch using GetFakeLSNForUnloggedRel() instead of the
atomic counter. I think this looks much nicer and less invasive, as it
simply uses XLogCtl shared memory (instead of having to pass a new
pointer everywhere).
We still need to pass the is_parallel flag, though. I wonder i
On 7/30/24 1:31 PM, Andrey M. Borodin wrote:>> On 30 Jul 2024, at 14:57,
Tomas Vondra wrote:
How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just bump
XLogCtl->unloggedLSN if necessary?
Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared counter? As
On 7/30/24 13:31, Andrey M. Borodin wrote:
>
>
>> On 30 Jul 2024, at 14:57, Tomas Vondra wrote:
>>
>>>
>>> How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN?
>>> Just bump XLogCtl->unloggedLSN if necessary?
>>> Perhaps, consider using GetFakeLSNForUnloggedRel() instead o
> On 30 Jul 2024, at 14:57, Tomas Vondra wrote:
>
>>
>> How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just
>> bump XLogCtl->unloggedLSN if necessary?
>> Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared
>> counter? As long as we do not care about
On 7/30/24 11:39, Andrey M. Borodin wrote:
>
>
>> On 30 Jul 2024, at 14:05, Tomas Vondra wrote:
>>
>>
>>
>> On 7/26/24 14:13, Andrey M. Borodin wrote:
>>>
>>>
On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
I feel the tricky part about doing that is that we need to make sure
> On 30 Jul 2024, at 14:05, Tomas Vondra wrote:
>
>
>
> On 7/26/24 14:13, Andrey M. Borodin wrote:
>>
>>
>>> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>>>
>>> I feel the tricky part about doing that is that we need to make sure the
>>> fake LSNs are all less than the current rea
On 7/26/24 14:13, Andrey M. Borodin wrote:
>
>
>> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>>
>> I feel the tricky part about doing that is that we need to make sure the
>> fake LSNs are all less than the current real LSN when the index build
>> completes and while that normally sho
> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>
> I feel the tricky part about doing that is that we need to make sure the fake
> LSNs are all less than the current real LSN when the index build completes
> and while that normally should be the case we will have a almost never
> exerc
On 7/22/24 2:08 PM, Andrey M. Borodin wrote:
During inserting tuples we need NSN on page. For NSN we can use just a counter,
generated by gistGetFakeLSN() which in turn will call
GetFakeLSNForUnloggedRel(). Or any other shared counter.
After inserting tuples we call log_newpage_range() to actua
> On 22 Jul 2024, at 14:53, Tomas Vondra wrote:
>
>
>
> On 7/22/24 13:08, Andrey M. Borodin wrote:
>>
>>
>>> On 22 Jul 2024, at 12:26, Tomas Vondra
>>> wrote:
>>>
>>> I don't understand how would that solve the problem, can you
>>> elaborate? Which of the values are you suggesting should
On 7/22/24 13:08, Andrey M. Borodin wrote:
>
>
>> On 22 Jul 2024, at 12:26, Tomas Vondra
>> wrote:
>>
>> I don't understand how would that solve the problem, can you
>> elaborate? Which of the values are you suggesting should be
>> replaced with the shared counter? lastlsn?
>
> I think duri
> On 22 Jul 2024, at 12:26, Tomas Vondra wrote:
>
> I don't understand how would that solve the problem, can you elaborate?
> Which of the values are you suggesting should be replaced with the
> shared counter? lastlsn?
I think during build we should consider index unlogged and always use
Ge
On 7/22/24 11:00, Andrey M. Borodin wrote:
>
>
>> On 21 Jul 2024, at 23:42, Tomas Vondra wrote:
>>
>>>
>>> 1. Do I get it right that is_parallel argument for gistGetFakeLSN()
>>> is only needed for assertion? And this assertion can be ensured just
>>> by inspecting code. Is it really necessary?
> On 21 Jul 2024, at 23:42, Tomas Vondra wrote:
>
>>
>> 1. Do I get it right that is_parallel argument for gistGetFakeLSN()
>> is only needed for assertion? And this assertion can be ensured just
>> by inspecting code. Is it really necessary?
>
> Yes, in the patch it's only used for an asser
On 7/21/24 21:31, Andrey M. Borodin wrote:
> Hi Tomas!
>
>> On 7 Jun 2024, at 20:41, Tomas Vondra
>> wrote:
>>
>> After looking into parallel builds for BRIN and GIN indexes, I was
>> wondering if there's a way to do parallel builds for GiST too. I
>> knew next to nothing about how GiST works,
Hi Tomas!
> On 7 Jun 2024, at 20:41, Tomas Vondra wrote:
>
> After looking into parallel builds for BRIN and GIN indexes, I was
> wondering if there's a way to do parallel builds for GiST too. I knew
> next to nothing about how GiST works, but I gave it a shot and here's
> what I have - the atta
Hi,
I've done a number of experiments with the GiST parallel builds, both
with the sorted and unsorted cases, so let me share some of the results
and conclusions from that.
In the first post I did some benchmarks using btree_gist, but that
seemed not very realistic - there certainly are much more
21 matches
Mail list logo