Yes, the ids is something I don't like either.
They carry additional semantics, which I cannot make go away.
How are chances char(20) is more time efficient than numeric(20)?
Disk space is no problem here.
On 12.01.2013, at 02:17, Claudio Freire wrote:
> On Fri, Jan 11, 2013 at 8:55 PM, Horst D
On Fri, Jan 11, 2013 at 5:17 PM, Claudio Freire wrote:
> On Fri, Jan 11, 2013 at 8:55 PM, Horst Dehmer wrote:
>> Except - and that's the wall I'm hitting - for one table which yielded just
>> 75 records/second.
>> The main 'problem' seem to be the FK constraints. Dropping just them
>> restored in
On Sat, Jan 12, 2013 at 5:16 PM, Horst Dehmer wrote:
> Yes, the ids is something I don't like either.
> They carry additional semantics, which I cannot make go away.
> How are chances char(20) is more time efficient than numeric(20)?
> Disk space is no problem here.
What are the other tables like
Jeff Janes writes:
> Will PG allow you to add a FK constraint where there is no usable
> index on the referenced side?
It will not, because the referenced side must have a unique constraint,
ie an index.
The standard performance gotcha here is not having an index on the
referencing side. But th
The types referenced by the foreign keys are the same Numeric(20).
Since the complete schema (of about 300 tables) is generated, I will just try
char(20) instead of numeric(20) in the next days to see if it makes any
difference. Which I somehow doubt.
But first I'm following the lead of the ta
On Sat, Jan 12, 2013 at 7:41 PM, Horst Dehmer wrote:
> Since the complete schema (of about 300 tables) is generated, I will just try
> char(20) instead of numeric(20) in the next days to see if it makes any
> difference. Which I somehow doubt.
I think that might just make it worse.
Well, maybe
