>
>
> > On Tue, Apr 30, 2019 at 5:44 AM Tom Lane wrote:
> >> FWIW, my recommendation for this sort of thing is almost always
> >> to not use CHAR(n). The use-case for that datatype pretty much
> >> disappeared with the last IBM Model 029 card punch.
> ...
>
>
>
Perhaps the "tip" on the character
I agree in principle, however in this particular scenario it's not
our schema so we're a little reluctant to migrate the types etc.
We're in a bit of a bad place because the combination of NHibernate
+ npgsql3/4 + this table = seqScans everywhere. Basically when npgsql
changed their default type
Rob writes:
> Basically, if a table exists with a PK which is CHAR(n) and a query is
> sent with VARCHAR or CHAR then it uses an Index Scan. If the query is
> sent with TEXT as the type then postgresql casts the column to TEXT
> (rather than the value to CHAR) and it does a Seq Scan.
Yeah, this i
Hi Guys,
I wanted to get some thoughts about a type-specific performance problem
we hit
through our application tier.
The full conversation is here:
https://github.com/npgsql/npgsql/issues/2283
Basically, if a table exists with a PK which is CHAR(n) and a query is
sent with
VARCHAR or CHAR
