On 12/6/21 02:47, Tom Lane wrote:
Tomas Vondra writes:
On 12/5/21 21:16, Tom Lane wrote:
Oh, geez. *Please* let us not add another regression failure mode
like the ones that afflict stats.sql. We do not need a doubling
of that failure rate. I suggest just removing this test.
Whooops. Agr
Tomas Vondra writes:
> On 12/5/21 21:16, Tom Lane wrote:
>> Oh, geez. *Please* let us not add another regression failure mode
>> like the ones that afflict stats.sql. We do not need a doubling
>> of that failure rate. I suggest just removing this test.
> Whooops. Agreed, I'll get rid of that t
On 12/5/21 21:16, Tom Lane wrote:
Justin Pryzby writes:
brin.sql's new brin_hot test is failing sometimes.
Evidently because:
| 2021-12-01 04:02:01.096 CET [61a6e587.3106b1:4] LOG: wait_for_hot_stats
delayed 33.217301 seconds
It seems like maybe the UDP packet lost to the stats collector got
Justin Pryzby writes:
> brin.sql's new brin_hot test is failing sometimes.
> Evidently because:
> | 2021-12-01 04:02:01.096 CET [61a6e587.3106b1:4] LOG: wait_for_hot_stats
> delayed 33.217301 seconds
> It seems like maybe the UDP packet lost to the stats collector got lost ?
> It fails less than
On Tue, Nov 30, 2021 at 08:11:03PM +0100, Tomas Vondra wrote:
> OK,
>
> I've polished the last version of the patch a bit (added a regression test
> with update of attribute in index predicate and docs about the new flag into
> indexam.sgml) and pushed.
brin.sql's new brin_hot test is failing som
út 30. 11. 2021 v 20:11 odesílatel Tomas Vondra
napsal:
>
> OK,
>
> I've polished the last version of the patch a bit (added a regression
> test with update of attribute in index predicate and docs about the new
> flag into indexam.sgml) and pushed.
Thanks a lot for taking over this, improving an
OK,
I've polished the last version of the patch a bit (added a regression
test with update of attribute in index predicate and docs about the new
flag into indexam.sgml) and pushed.
I wonder if we could/should improve handling of index predicates. In
particular, it seems to me we could simpl
Hi,
I've polished the patch a bit, with the goal to get it committed. I've
added the new amhotblocking flag to indexam.sgml (and I'm wondering if
there's another place in docs for more details).
But then I realized there's an issue in handling the predicate. Consider
this example:
drop t
po 4. 10. 2021 v 16:17 odesílatel Tomas Vondra
napsal:
>
> Hi,
>
> I took a look at this patch again to see if I can get it polished and
> fixed. Per the discussion, I've removed the rd_indexattr list and
> replaced it with a simple flag. While doing so, I noticed a couple of
> places that should
Hi,
I took a look at this patch again to see if I can get it polished and
fixed. Per the discussion, I've removed the rd_indexattr list and
replaced it with a simple flag. While doing so, I noticed a couple of
places that should have consider (init or free) rd_hotblockingattr.
Patch 0001 is
po 12. 7. 2021 v 23:15 odesílatel Tomas Vondra
napsal:
>
>
>
> On 7/12/21 11:02 PM, Alvaro Herrera wrote:
> > On 2021-Jul-12, Josef Šimánek wrote:
> >
> >>> 2) Do we actually need to calculate and store hotblockingattrs
> >>> separately in RelationGetIndexAttrBitmap? It seems to me it's either
> >
On 2021-Jul-12, Tomas Vondra wrote:
> I'm not sure how to verify no external code depends on that flag. I have
> no idea if there's a plausible use case for it, though.
But we don't *have* to, do we?
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Tiene valor a
On 7/12/21 11:02 PM, Alvaro Herrera wrote:
> On 2021-Jul-12, Josef Šimánek wrote:
>
>>> 2) Do we actually need to calculate and store hotblockingattrs
>>> separately in RelationGetIndexAttrBitmap? It seems to me it's either
>>> NULL (with amhotblocking=false) or equal to indexattrs. So why not
On 2021-Jul-12, Josef Šimánek wrote:
> > 2) Do we actually need to calculate and store hotblockingattrs
> > separately in RelationGetIndexAttrBitmap? It seems to me it's either
> > NULL (with amhotblocking=false) or equal to indexattrs. So why not to
> > just get rid of hotblockingattr and rd_hotb
On 7/12/21 10:55 PM, Alvaro Herrera wrote:
> On 2021-Jul-12, Tomas Vondra wrote:
>
>> Well, one of us is confused and it might be me ;-)
>
> :-)
>
>> The point is that BRIN is the only index type with amhotblocking=false,
>> so it would return NULL (and thus it does not block HOT). All other
>>
On 2021-Jul-12, Tomas Vondra wrote:
> Well, one of us is confused and it might be me ;-)
:-)
> The point is that BRIN is the only index type with amhotblocking=false,
> so it would return NULL (and thus it does not block HOT). All other
> indexes AMs have amblocking=true and so should return rd_
On 7/12/21 10:45 PM, Josef Šimánek wrote:
> po 12. 7. 2021 v 22:31 odesílatel Tomas Vondra
> napsal:
>>
>> On 6/30/21 1:43 AM, Josef Šimánek wrote:
>>> st 30. 6. 2021 v 1:20 odesílatel Tomas Vondra
>>> napsal:
On 6/30/21 12:53 AM, Josef Šimánek wrote:
> st 30. 6. 2021 v
po 12. 7. 2021 v 22:31 odesílatel Tomas Vondra
napsal:
>
> On 6/30/21 1:43 AM, Josef Šimánek wrote:
> > st 30. 6. 2021 v 1:20 odesílatel Tomas Vondra
> > napsal:
> >>
> >>
> >>
> >> On 6/30/21 12:53 AM, Josef Šimánek wrote:
> >>> st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek
> >>> napsal:
> >>
On 7/12/21 10:37 PM, Alvaro Herrera wrote:
> On 2021-Jul-12, Tomas Vondra wrote:
>
>> 2) Do we actually need to calculate and store hotblockingattrs
>> separately in RelationGetIndexAttrBitmap? It seems to me it's either
>> NULL (with amhotblocking=false) or equal to indexattrs. So why not to
>
On 2021-Jul-12, Tomas Vondra wrote:
> 2) Do we actually need to calculate and store hotblockingattrs
> separately in RelationGetIndexAttrBitmap? It seems to me it's either
> NULL (with amhotblocking=false) or equal to indexattrs. So why not to
> just get rid of hotblockingattr and rd_hotblockingat
On 6/30/21 1:43 AM, Josef Šimánek wrote:
> st 30. 6. 2021 v 1:20 odesílatel Tomas Vondra
> napsal:
>>
>>
>>
>> On 6/30/21 12:53 AM, Josef Šimánek wrote:
>>> st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek
>>> napsal:
Hello!
Tomáš Vondra has shared a few ideas to improve BRIN i
st 30. 6. 2021 v 1:20 odesílatel Tomas Vondra
napsal:
>
>
>
> On 6/30/21 12:53 AM, Josef Šimánek wrote:
> > st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek
> > napsal:
> >>
> >> Hello!
> >>
> >> Tomáš Vondra has shared a few ideas to improve BRIN index in czech
> >> PostgreSQL mail list some time
On 6/30/21 12:53 AM, Josef Šimánek wrote:
st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek napsal:
Hello!
Tomáš Vondra has shared a few ideas to improve BRIN index in czech
PostgreSQL mail list some time ago [1 , in czech only]. This is first
try to implement one of those ideas.
Currently B
st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek napsal:
>
> Hello!
>
> Tomáš Vondra has shared a few ideas to improve BRIN index in czech
> PostgreSQL mail list some time ago [1 , in czech only]. This is first
> try to implement one of those ideas.
>
> Currently BRIN index blocks HOT update even it
Hello!
Tomáš Vondra has shared a few ideas to improve BRIN index in czech
PostgreSQL mail list some time ago [1 , in czech only]. This is first
try to implement one of those ideas.
Currently BRIN index blocks HOT update even it is not linked tuples
directly. I'm attaching the initial patch allowi
25 matches
Mail list logo
