Just brainstorming here. Another crazy idea would be to get rid of
"name" data type, at least from the user-visible planner point of
view. It would probably have to be stored as a fixed length data type
like today but with a one-byte length header. That would make it
possible for the planner to use
I wrote:
> ... However, I wonder what people would think of a
> more aggressive approach, viz:
> -CREATE DOMAIN sql_identifier AS character varying COLLATE "C";
> +CREATE DOMAIN sql_identifier AS name;
>
> I've not checked to verify that sql_identifier is used for all and only
> those view columns
čt 20. 12. 2018 v 5:29 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 20. 12. 2018 v 0:14 odesílatel Tom Lane napsal:
> >> After my last few commits, the only issue that's left here is the
> >> cast-to-varchar implied by casting to sql_identifier. Upthread
> >> I showed a possible
Pavel Stehule writes:
> čt 20. 12. 2018 v 0:14 odesílatel Tom Lane napsal:
>> After my last few commits, the only issue that's left here is the
>> cast-to-varchar implied by casting to sql_identifier. Upthread
>> I showed a possible planner hack to get rid of that, and we could
>> still solve it
čt 20. 12. 2018 v 0:14 odesílatel Tom Lane napsal:
> I wrote:
> > Pavel Stehule writes:
> >> Slow query
> >> select * from information_schema.tables where table_name = 'pg_class';
>
> > Yeah. This has been complained of many times before.
>
> > The core of the problem, I think, is that we're un
I wrote:
> Pavel Stehule writes:
>> Slow query
>> select * from information_schema.tables where table_name = 'pg_class';
> Yeah. This has been complained of many times before.
> The core of the problem, I think, is that we're unable to convert the
> condition on table_name into an indexscan on
Robert Haas writes:
> On Thu, Dec 6, 2018 at 12:50 PM Tom Lane wrote:
>> No. You need to do AIM *after* obtaining the lock, else you still
>> have the race condition that you can execute a query on a table
>> without being aware of recent DDL on it.
> Huh? The call in relation_openrv_extended()
On Thu, Dec 6, 2018 at 12:50 PM Tom Lane wrote:
> > If we called it at the start of every query, couldn't we dispense with
> > the call in relation_openrv_extended()?
>
> No. You need to do AIM *after* obtaining the lock, else you still
> have the race condition that you can execute a query on a
Robert Haas writes:
> On Thu, Dec 6, 2018 at 12:03 PM Tom Lane wrote:
>> [ further experimentation... ] It looks like if you prepare
>> a query and then just execute it repeatedly in one transaction,
>> you'd not reach AIM (as long as you were getting generic plans).
>> Possibly that's a gap wor
On Thu, Dec 6, 2018 at 12:03 PM Tom Lane wrote:
> In my testing, that still hits AIM() during parserOpenTable().
Oh, I see. relation_openrv_extended() calls it.
> [ further experimentation... ] It looks like if you prepare
> a query and then just execute it repeatedly in one transaction,
> you
Robert Haas writes:
> On Thu, Dec 6, 2018 at 11:32 AM Tom Lane wrote:
>> It's fairly hard to imagine practical cases where we'd not call
>> AcceptInvalidationMessages at least once per query, so I'm not
>> very sure what you're on about.
> Unless I'm confused, it happens any time you run a query
On Thu, Dec 6, 2018 at 11:32 AM Tom Lane wrote:
> Robert Haas writes:
> > I'm not thrilled about depending on sinval without locking,
> > particularly given that my proposal to make sure we
> > AcceptInvalidationMessages() at least once per query was shouted down.
>
> It's fairly hard to imagine
Robert Haas writes:
> I'm not thrilled about depending on sinval without locking,
> particularly given that my proposal to make sure we
> AcceptInvalidationMessages() at least once per query was shouted down.
It's fairly hard to imagine practical cases where we'd not call
AcceptInvalidationMessag
On Wed, Dec 5, 2018 at 1:41 PM Tom Lane wrote:
> Ah, yes, that is a case where we might have enough knowledge to prove
> the test redundant --- but considering that we explicitly discourage
> domain NOT NULL as bad style and not fully supported, I can't get
> excited about it. I suppose in some c
On 2018-12-05 13:41:32 -0500, Tom Lane wrote:
> The bigger picture here is that people seem to like to use domains
> as simple type aliases, which will never have any constraints, but
> we're very dumb about that today. So the patch as presented seems
> like it has lots of potential applicability,
Andres Freund writes:
> On 2018-12-05 13:22:23 -0500, Tom Lane wrote:
>> Not following what you have in mind here? My 0002 throws away the
>> CoerceToDomain if there are *no* constraints, but I can't see any
>> situation in which we'd likely be able to ignore a constraint,
>> simple or not.
> Ye
Hi,
On 2018-12-05 13:22:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-05 12:24:54 -0500, Tom Lane wrote:
> >> There are two different issues in that. One is that the domain might
> >> have constraints (though in reality it does not), so the planner can't
> >> throw away the Co
Andres Freund writes:
> On 2018-12-05 12:24:54 -0500, Tom Lane wrote:
>> There are two different issues in that. One is that the domain might
>> have constraints (though in reality it does not), so the planner can't
>> throw away the CoerceToDomain node, and thus can't match the expression
>> to
Hi,
On 2018-12-05 12:24:54 -0500, Tom Lane wrote:
> The core of the problem, I think, is that we're unable to convert the
> condition on table_name into an indexscan on pg_class.relname, because
> the view has cast pg_class.relname to the sql_identifier domain.
>
> There are two different issues i
Pavel Stehule writes:
> Slow query
> select * from information_schema.tables where table_name = 'pg_class';
Yeah. This has been complained of many times before.
The core of the problem, I think, is that we're unable to convert the
condition on table_name into an indexscan on pg_class.relname, b
20 matches
Mail list logo
