From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Doug Mitchell <doug(at)mitchcraft(dot)com>, pgsql-bugs(at)postgreSQL(dot)org |
Subject: | Re: [BUGS] General Bug Report: Files greater than 1 GB are created while sorting |
Date: | 1999-07-09 03:48:37 |
Message-ID: | 199907090348.XAA07190@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I have renamed these sort temp tables to pg_sorttemp so they will not be
> > confused with actual temp tables.
>
> I didn't realize that the names generated for temp tables were so close
> to those generated for temp files. Changing one or the other does seem
> like a good idea. But I do not like "pg_sorttemp" because fd.c's
> temporary-file mechanism is used for more things than just sorting.
> Hash joins, for example. Can we think of a better name?
I am open to other names. It is really for joining and sorting.
Suggestions?
>
> Alternatively, how about including the user-given name for a temp table
> into its real name? That would be helpful for debugging, I'm sure.
> I'm thinking of something like
>
> snprintf(newrelname, NAMEDATALEN, "pg_temp.%d.%u.%s",
> (int) MyProcPid, uniqueId++, userrelname);
>
> (relying on snprintf to truncate the user name if too long, here).
You can only do the truncation of the user-supplied part, not the actual
numbers. I guess we could. I wanted it to be uniform, I guess.
> Note that under ordinary circumstances, the data being processed by a
> sort or hash join will be written into several temp files that each get
> just a fraction of the data; so you would not actually see a problem
> until you got to several-times-2-Gig total data volume.
He already has 1.4 gig sort files.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | sszabo | 1999-07-09 16:17:23 | Re: [BUGS] General Bug Report: GROUP BY with NULL not done properly(Oracle8& DB/2 do this completely different) |
Previous Message | Bruce Momjian | 1999-07-09 03:37:25 | Re: [BUGS] General Bug Report: GROUP BY with NULL not done properly(Oracle8& DB/2 do this completely different) |