Le 11/12/2014 00:46, Tom Lane a écrit :
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
As far as that goes, I think the OP was unhappy about the performance
of the information_schema views, which in our implementation do exactly
that so that the exposed types of
Thomas Reiss thomas.re...@dalibo.com wrote:
postgres=# create table test1 (a text);
CREATE TABLE
postgres=# insert into test1 select generate_series(1,10);
INSERT 0 10
postgres=# create index idx1 on test1(a);
CREATE INDEX
postgres=# analyze test1 ;
ANALYZE;
postgres=# explain
Kevin Grittner kgri...@ymail.com writes:
It's kinda hard for me to visualize where it makes sense to define
the original table column as the bare type but use a domain when
referencing it in the view.
As far as that goes, I think the OP was unhappy about the performance
of the
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
It's kinda hard for me to visualize where it makes sense to define
the original table column as the bare type but use a domain when
referencing it in the view.
As far as that goes, I think the OP was unhappy about
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
As far as that goes, I think the OP was unhappy about the performance
of the information_schema views, which in our implementation do exactly
that so that the exposed types of the view columns conform to the SQL
Le 08/12/2014 16:18, Tom Lane a écrit :
Thomas Reiss thomas.re...@dalibo.com writes:
postgres=# explain select * from test2 where a='toto';
QUERY PLAN
--
Seq Scan on test1 (cost=0.00..1693.00 rows=500 width=5)
Hello all,
We experienced some casting issues with domains. We experienced the
problem while querying the information_schema btw, but here is a simpler
test case :
postgres=# create table test1 (a text);
CREATE TABLE
postgres=# insert into test1 select generate_series(1,10);
INSERT 0 10
Thomas Reiss thomas.re...@dalibo.com writes:
postgres=# explain select * from test2 where a='toto';
QUERY PLAN
--
Seq Scan on test1 (cost=0.00..1693.00 rows=500 width=5)
Filter: (((a)::tstdom)::text =
On 12/8/14, 9:18 AM, Tom Lane wrote:
The short answer is that SQL domains are not zero-cost type aliases.
Perhaps there would be value in having a feature that*is* a a zero-cost
alias, but it wouldn't be a domain.
Note that you can actually re-use the support functions of one data type to
