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
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
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
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
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
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
