Hi!
It would be nice to have tablespaces for each users. This is a small
pathc that does the job.
- gramar file: alter|create user ... with default tablespace 'tblspc'
added;
- new column in pg_authid: roltblspc, an Oid referring to the pg_tablespace
- at alter/add role neccessary default
Laszlo Hornyak [EMAIL PROTECTED] writes:
It would be nice to have tablespaces for each users. This is a small
pathc that does the job.
Isn't this entirely redundant with the existing default_tablespace GUC
variable, ie,
ALTER USER foo SET default_tablespace = whatever;
The patch's behavior
Here are comments that Daniel McNeil made earlier, which I've neglected
to forward earlier. I've cc'ed him and Mark Havercamp, which some of
you got to meet the other day.
Mark
-
With O_DIRECT on Linux, when the write() returns the i/o has been
transferred to the disk.
Normally, this
Alon Goldshuv [EMAIL PROTECTED] writes:
New patch attached. It includes very minor changes. These are changes that
were committed to CVS 3 weeks ago (copy.c 1.247) which I missed in the
previous patch.
I've applied this with (rather extensive) revisions. I didn't like what
you had done with
Tom,
Thanks for finding the bugs and reworking things.
I had some difficulty in generating test cases that weren't largely
I/O-bound, but AFAICT the patch as applied is about the same speed
as what you submitted.
You achieve the important objective of knocking the parsing stage down a
lot,
Tom,
The previous timings were for a table with 15 columns of mixed type. We
also test with 1 column to make the parsing overhead more apparent. In the
case of 1 text column with 145MB of input data:
Your patch:
Time: 6612.599 ms
Alon's patch:
Time: 6119.244 ms
Alon's patch is 7.5%
Tom,
My direct e-mails to you are apparently blocked, so I'll send this to the
list.
I've attached the case we use for load performance testing, with the data
generator modified to produce a single row version of the dataset.
I do believe that you/we will need to invert the processing loop to
Luke Lonergan [EMAIL PROTECTED] writes:
I had some difficulty in generating test cases that weren't largely
I/O-bound, but AFAICT the patch as applied is about the same speed
as what you submitted.
You achieve the important objective of knocking the parsing stage down a
lot, but your parsing
Tom,
On 8/6/05 9:08 PM, Tom Lane [EMAIL PROTECTED] wrote:
Luke Lonergan [EMAIL PROTECTED] writes:
I had some difficulty in generating test cases that weren't largely
I/O-bound, but AFAICT the patch as applied is about the same speed
as what you submitted.
You achieve the important
