Hi,
Rod Taylor wrote:
> On Fri, 2002-11-15 at 16:18, Josh Berkus wrote:
> > Rod,
> >
> > > > Hmmm ... how big *is* that varchar field? 8 characters gives us about 6mb
> > for
> > > > the column. Of course, if it's a 128-char global unque id, that;s a bit
> > > > larger.
> > >
> > > 20 characters long in the Unicode locale -- which is 40 bytes?
> >
> > Well, 40+, probably about 43. Should be about 29mb, yes?
> > Here's a question: is the total size of the column a good indicator of the
> > sort_mem required? Or does the rowsize affect it somehow?
>
> I'd suspect the total row is sorted, especially in this case where he's
> sorting more than one attribute.
>
I think that total the row is sorted.I do not know hoe is sorting in pg working and
why so slow,
but I tested all this in java ( in C is much quicker)
and the make this:
1. Read all data in memory defined as ArrayList from structure of data.
2. make comparator with unicode string compare.
3. Execute sort (all in memory)
The sort take 2-4 sek for all this rows!!!
It is good as performance.
The question is : Why is it in ps so slow?
Sorting is normal think for db!
Also I have 256 MB for sort mem and this was the only executing query at the moment.
I know that if the fields are INT all will work better, but we migrate this
application from oracle
and the fields in oracle was varchar.
We do not have any performance problems with oracle and this data.
Also one part from users will continue to work with oracle and exchange ( import and
export) data
to the pg systems.
> --
> Rod Taylor <rbt@rbt.ca>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)