Hi Andrey,
> >> only performance issues
> >
> > That's interesting. Any chance you could share the hardware
> > description, the configuration file, and steps to reproduce with us?
> >
> I didn't control execution time exactly. Because it is a join of two
> empty tables. As I see, this join used
On 14/9/21 16:37, Aleksander Alekseev wrote:
Hi Andrey,
only performance issues
That's interesting. Any chance you could share the hardware
description, the configuration file, and steps to reproduce with us?
I didn't control execution time exactly. Because it is a join of two
empty
"Andrey V. Lepikhov" writes:
> Also, as a test, I used two tables with 1E5 partitions each. I tried to
> do plain SELECT, JOIN, join with plain table. No errors found, only
> performance issues. But it is a subject for another research.
Yeah, there's no expectation that the performance would
Hi Andrey,
> only performance issues
That's interesting. Any chance you could share the hardware
description, the configuration file, and steps to reproduce with us?
--
Best regards,
Aleksander Alekseev
On 9/11/21 10:37 PM, Tom Lane wrote:
Aleksander Alekseev writes:
(v2 below is a rebase up to HEAD; no actual code changes except
for adjusting the definition of IS_SPECIAL_VARNO.)
I have looked at this code. No problems found.
Also, as a test, I used two tables with 1E5 partitions each. I
Andrey Lepikhov writes:
> But why the Index type still uses for indexing of range table entries?
> For example:
> - we give int resultRelation value to create_modifytable_path() as Index
> nominalRelation value.
> - exec_rt_fetch(Index) calls list_nth(int).
> - generate_subquery_vars() accepts
Aleksander Alekseev writes:
> +1. The proposed changes will be beneficial in the long term. They
> will affect existing extensions. However, the scale of the problem
> seems to be exaggerated.
Yeah, after thinking more about this I agree we should just do it.
I do not say that David's concerns
Hi hackers,
> > So I'm inclined to propose pushing this and seeing what happens.
>
> +1
+1. The proposed changes will be beneficial in the long term. They
will affect existing extensions. However, the scale of the problem
seems to be exaggerated.
I can confirm that the patch passes
On 2/7/21 21:23, Tom Lane wrote:
So I'm inclined to propose pushing this and seeing what happens.
+1
But why the Index type still uses for indexing of range table entries?
For example:
- we give int resultRelation value to create_modifytable_path() as Index
nominalRelation value.
-
David Rowley writes:
> Is this really sane?
> As much as I would like to see the 65k limit removed, I just have
> reservations about fixing it in this way. Even if we get all the
> cases fixed in core, there's likely a whole bunch of extensions
> that'll have bugs as a result of this for many
On Sat, 3 Jul 2021 at 06:23, Tom Lane wrote:
> So I'm inclined to propose pushing this and seeing what happens.
Is this really sane?
As much as I would like to see the 65k limit removed, I just have
reservations about fixing it in this way. Even if we get all the
cases fixed in core, there's
Here's a more fleshed-out version of this patch. I ran around and
fixed all the places where INNER_VAR etc. were being assigned directly to
a variable or parameter of type Index, and also grepped for 'Index.*varno'
to find suspicious declarations. (I didn't change every last instance
of the
On 4/8/21 8:13 AM, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
Can we move forward with this?
We could just push the change and see what happens. But I was thinking
more in terms of doing that early in the v15 cycle. I remain skeptical
that we need a near-term fix.
To make sure
I wrote:
> Peter Eisentraut writes:
>> Can we move forward with this?
> We could just push the change and see what happens. But I was thinking
> more in terms of doing that early in the v15 cycle. I remain skeptical
> that we need a near-term fix.
To make sure we don't forget, I added an
Peter Eisentraut writes:
> Can we move forward with this?
> I suppose there was still some uncertainty about whether all the places
> that need changing have been identified, but do we have a better idea
> how to find them?
We could just push the change and see what happens. But I was
On 06.03.21 15:59, Tom Lane wrote:
Peter Eisentraut writes:
On 04.03.21 20:01, Tom Lane wrote:
(2) Does that datatype change need to propagate anywhere besides
what I touched here? I did not make any effort to search for
other places.
I think
Var.varnosyn
CurrentOfExpr.cvarno
should
Peter Eisentraut writes:
> On 04.03.21 20:01, Tom Lane wrote:
>> (2) Does that datatype change need to propagate anywhere besides
>> what I touched here? I did not make any effort to search for
>> other places.
> I think
> Var.varnosyn
> CurrentOfExpr.cvarno
> should also have their type
On 04.03.21 20:01, Tom Lane wrote:
Just as a proof of concept, I tried the attached, and it passes
check-world. So if there's anyplace trying to stuff OUTER_VAR and
friends into bitmapsets, it's pretty far off the beaten track.
The main loose ends that'd have to be settled seem to be:
(1)
Just as a proof of concept, I tried the attached, and it passes
check-world. So if there's anyplace trying to stuff OUTER_VAR and
friends into bitmapsets, it's pretty far off the beaten track.
The main loose ends that'd have to be settled seem to be:
(1) What data type do we want Var.varno to
Tomas Vondra writes:
> On 3/4/21 4:16 PM, Tom Lane wrote:
>> Hmm, do we really have any places that include OUTER_VAR etc in
>> bitmapsets? They shouldn't appear in relid sets, for sure.
>> I agree though that if they did, this would have bad performance
>> consequences.
> Hmmm, I don't know. I
On 3/4/21 4:16 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> IMO just bumping up the constants from ~65k to 1M is a net loss, for
>> most users. We add this to bitmapsets, which means we're using ~8kB with
>> the current values, but this jumps to 128kB with this higher value. This
>> also means
Tomas Vondra writes:
> IMO just bumping up the constants from ~65k to 1M is a net loss, for
> most users. We add this to bitmapsets, which means we're using ~8kB with
> the current values, but this jumps to 128kB with this higher value. This
> also means bms_next_member etc. have to walk much
On 3/4/21 8:43 AM, Andrey Lepikhov wrote:
> On 3/3/21 12:52, Julien Rouhaud wrote:
>> On Wed, Mar 3, 2021 at 4:57 PM Amit Langote
>> wrote:
>>>
>>> On Wed, Mar 3, 2021 at 5:52 PM David Rowley
>>> wrote:
Something like 1 million seems like a more realistic limit to me.
That might
On 3/3/21 12:52, Julien Rouhaud wrote:
On Wed, Mar 3, 2021 at 4:57 PM Amit Langote wrote:
On Wed, Mar 3, 2021 at 5:52 PM David Rowley wrote:
Something like 1 million seems like a more realistic limit to me.
That might still be on the high side, but it'll likely mean we'd not
need to revisit
Amit Langote writes:
> Also, I got reminded of this discussion from not so long ago:
> https://www.postgresql.org/message-id/flat/16302-e45634e2c0e34e97%40postgresql.org
Yeah. Nobody seems to have pursued Peter's idea of changing the magic
values to small negative ones, but that seems like a
On Wed, Mar 3, 2021 at 4:57 PM Amit Langote wrote:
>
> On Wed, Mar 3, 2021 at 5:52 PM David Rowley wrote:
> > Something like 1 million seems like a more realistic limit to me.
> > That might still be on the high side, but it'll likely mean we'd not
> > need to revisit this for quite a while.
>
>
On Wed, Mar 3, 2021 at 5:52 PM David Rowley wrote:
> On Wed, 3 Mar 2021 at 21:29, Andrey Lepikhov
> wrote:
> >
> > Playing with a large value of partitions I caught the limit with 65000
> > table entries in a query plan:
> >
> > if (IS_SPECIAL_VARNO(list_length(glob->finalrtable)))
> >
On Wed, 3 Mar 2021 at 21:29, Andrey Lepikhov wrote:
>
> Playing with a large value of partitions I caught the limit with 65000
> table entries in a query plan:
>
> if (IS_SPECIAL_VARNO(list_length(glob->finalrtable)))
> ereport(ERROR,
>
Hi,
Playing with a large value of partitions I caught the limit with 65000
table entries in a query plan:
if (IS_SPECIAL_VARNO(list_length(glob->finalrtable)))
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("too many range table
29 matches
Mail list logo
