Tom Lane wrote:
John Arbash Meinel <[EMAIL PROTECTED]> writes:I've just tried to uncomment the settings for these parameters with with no impact on the query speed.
How about a quick side track.
Have you played around with your shared_buffers, maintenance_work_mem,
and work_mem settings?
Indeed. The hash joins seem unreasonably slow considering how little
data they are processing (unless this is being run on some ancient
toaster...). One thought that comes to mind is that work_mem may be
set so small that the hashes are forced into multiple batches.
shared_buffers = 48000 # min 16, at least max_connections*2, 8KB each
work_mem = 1024 # min 64, size in KB
maintenance_work_mem = 16384 # min 1024, size in KB
max_stack_depth = 2048 # min 100, size in KB
Another question worth asking is what are the data types of the columnsI have checked this and there are some JOINs smallint against integer. Is that problem? I would use smallint for IDPKs of some smaller tables but the lack of SMALLSERIAL and my laziness made me use SERIAL instead which is integer.
being joined on. If they are character types, what locale and encoding
is the database using?
That cost would be paid during the bottom-level scans though. The thingI've already posted the hardware info. OS is Linux (Gentoo) with kernel 2.6.11.
that strikes me here is that nearly all of the cost is being spent
joining.
What version of postgres are you using?
And what's the platform (hardware and OS)?
regards, tom laneMiroslav
begin:vcard fn;quoted-printable:Miroslav =C5=A0ulc n;quoted-printable:=C5=A0ulc;Miroslav org:StartNet s.r.o. adr;quoted-printable;quoted-printable:;;Vrchlick=C3=A9ho 161/5;Praha 5;;150 00;=C4=8Cesk=C3=A1 republika email;internet:[EMAIL PROTECTED] title:CEO tel;work:+420 257 225 602 tel;cell:+420 603 711 413 x-mozilla-html:TRUE url:http://www.startnet.cz version:2.1 end:vcard
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
