On Mon, 5 May 2008, Tom Lane wrote:
It bothers me a bit that the patch forces writes to be done "all of file
A in order, then all of file B in order, etc". We don't know enough
about the disk layout of the files to be sure that that's good. (This
might also mean that whether there is a win is
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sun, 4 May 2008, Tom Lane wrote:
>> Well, I tried a pgbench test similar to that one --- on smaller hardware
>> than was reported, so it was a bit smaller test case, but it should have
>> given similar results.
> ... If
> you're not offloading to anoth
Hello
I thing, all your comments are not problem. I'll send new version this week.
Thank You
Pavel Stehule
2008/5/5 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> this patch adds possibility to set additional options (SQLSTATE,
>> DETAIL, DETAIL_LOG and HINT) for
On Sun, 4 May 2008, Tom Lane wrote:
Well, I tried a pgbench test similar to that one --- on smaller hardware
than was reported, so it was a bit smaller test case, but it should have
given similar results.
My pet theory on cases where sorting will help suggests you may need a
write-caching co
2008/5/5 Tom Lane <[EMAIL PROTECTED]>:
> Applied with some revisions ---
>
> I added a timestamptz version; it didn't seem very appropriate to have
> only a timestamp version.
>
> You can't just pick a convenient-looking OID, you must use one that
> the unused_oids script reports as free.
I di
Brendan Jurd wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 2:37 AM, Tom Lane wrote:
The function names in the patch need schema-qualification in case
pg_catalog is not first in the search path.
Ah, yes. I should have seen that. Thanks Tom.
New v
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this patch adds possibility to set additional options (SQLSTATE,
> DETAIL, DETAIL_LOG and HINT) for RAISE statement,
I looked this over briefly. A couple of comments:
* Raising errors via hard-coded SQLSTATEs seems pretty unfriendly,
at least for cas
David Fetter wrote:
On Sun, May 04, 2008 at 07:49:25PM -0400, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
But it'll only be in \dT+ anyway, no?
Not in this patch.
Hmmm ... given that a long list of enum members would bloat the
o
On Sun, May 04, 2008 at 07:49:25PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But it'll only be in \dT+ anyway, no?
>
> > Not in this patch.
>
> Hmmm ... given that a long list of enum members would bloat the
> output quite a lot, I think I'd vote
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But it'll only be in \dT+ anyway, no?
> Not in this patch.
Hmmm ... given that a long list of enum members would bloat the output
quite a lot, I think I'd vote for putting it in \dT+.
regards, tom lane
--
S
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I notice that this patch adds an "Elements" column to the output of \dT,
which will only be used by enum types. That seems rather ... cluttered.
But it'll only be in \dT+ anyway, no?
Not in this
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sun, 4 May 2008, Tom Lane wrote:
>> However, I am completely unable to measure any performance improvement
>> from it. Given the possible risk of out-of-memory failures, I think the
>> patch should not be applied without some direct proof of performance
"H.Harada" <[EMAIL PROTECTED]> writes:
> Here's the sync and updated patch.
> It contains "strict" in catalog as well.
Applied with some revisions ---
I added a timestamptz version; it didn't seem very appropriate to have
only a timestamp version.
You can't just pick a convenient-looking OID, yo
On Sun, 4 May 2008, Tom Lane wrote:
However, I am completely unable to measure any performance improvement
from it. Given the possible risk of out-of-memory failures, I think the
patch should not be applied without some direct proof of performance
benefits, and I don't see any.
Fair enough.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I notice that this patch adds an "Elements" column to the output of \dT,
> which will only be used by enum types. That seems rather ... cluttered.
But it'll only be in \dT+ anyway, no?
regards, tom lane
--
Sent via pgsql-patc
On Sun, May 04, 2008 at 06:40:51PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>> Folks,
>>
>> In psql, \dT doesn't show the elements for enums. Please find
>> patch vs. CVS TIP attached which fixes this per the following TODO
>> item:
>>
>> http://archives.postgresql.org/pgsql-hackers/
David Fetter wrote:
Folks,
In psql, \dT doesn't show the elements for enums. Please find patch
vs. CVS TIP attached which fixes this per the following TODO item:
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php
I notice that this patch adds an "Elements" column to t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, May 4, 2008 at 10:55 AM, Tom Lane wrote:
> Andrew Dunstan writes:
> > Wouldn't this expression:
> > pg_catalog.array_to_string(c.relacl, chr(10))
> > be better expressed as
> > pg_catalog.array_to_string(c.relacl, E'\n')
>
>
"George Gensure" <[EMAIL PROTECTED]> writes:
> The new function name is pg_conf_load_time()
Applied with revisions.
> I'm now using LWLocks only on the backend in order to protect the
> PgReloadTime from mid copy reads. This may prove to be unnecessary,
> since the code to handle HUPs seems to b
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Well ... if somebody does want to change the representation of xml
> down the road, he's going to have to touch all the sites where the
> code converts to and from cstring anyway, right?
True.
> With that in mind, please find attached my followup patch
20 matches
Mail list logo
