Re: [PATCHES] New Turkish translations for 7.4 branch + an update for 8.0

2004-10-30 Thread Peter Eisentraut
Devrim GUNDUZ wrote: > Below are new Turkish translations for 7.4 branch: Installed. > Also, an update for 8.0 Also installed. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail com

[PATCHES] Cache last known per-tuple offsets to speed long tuple access

2004-10-30 Thread a_ogawa
I made a patch for "Cache last known per-tuple offsets to speed long tuple access" that is in TODO list. This problem was discussed on hackers-list as "Terrible performance on wide selects". The point of this problem is nocachegetattr() used from ExecEvalVar(). If tuple has

Re: [PATCHES] Win32 open items

2004-10-30 Thread Magnus Hagander
>I think Magnus had the right idea. We should invent a completely >separate opaque struct that contains *only* the fields that >PQrequestCancel actually needs (the hostname, port, and secret key; >anything else?) and make a function to create one of these from a >PQconn. This struct could then be

Re: [PATCHES] Cache last known per-tuple offsets to speed long tuple access

2004-10-30 Thread Tom Lane
a_ogawa <[EMAIL PROTECTED]> writes: > I made a patch for "Cache last known per-tuple offsets to speed > long tuple access" that is in TODO list. > I referred URL below for implementation. > http://archives.postgresql.org/pgsql-performance/2003-01/msg00262.php This wasn't quite what I had in mind

Re: [PATCHES] Win32 open items

2004-10-30 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Here is an attempt at this. First patch contains the changes to libpq, > second patch contains changes to psql to use this API. Docs not updated > yet, pending approval of the general idea at least :) I think it would be better to dispense with the P

Re: [PATCHES] Win32 open items

2004-10-30 Thread Magnus Hagander
>> Here is an attempt at this. First patch contains the changes >to libpq, >> second patch contains changes to psql to use this API. Docs >not updated >> yet, pending approval of the general idea at least :) > >I think it would be better to dispense with the PQgetCancelError >function and just ma

Re: [PATCHES] Win32 open items

2004-10-30 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> We don't need the cancelConnLock if this is done properly (at least, >> assuming that storing a pointer is atomic, which seems reasonable). > Anyway, consider this scenario. Thread A is the mainloop thread, Thread > B is the thread that handles Ctrl

Re: [PATCHES] Win32 open items

2004-10-30 Thread Magnus Hagander
>>> We don't need the cancelConnLock if this is done properly (at least, >>> assuming that storing a pointer is atomic, which seems reasonable). > >> Anyway, consider this scenario. Thread A is the mainloop >thread, Thread >> B is the thread that handles Ctrl-C. What if Thread B starts >its run a

Re: [PATCHES] Win32 open items

2004-10-30 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Ok, here we go with a new patch. Applied with a few minor revisions. > I started looking at docs, and reliased the PQrequestCancel() function > is documented under "async query processing". Is that really the correct > place? Probably not. I made

[PATCHES] Translation updates: pt_BR

2004-10-30 Thread Euler Taveira de Oliveira
Hi, Here is another update for pt_BR message files. I updated some comments and some fuzzy/untranslated messages. It's too big so I put it here: http://br.geocities.com/eulerto/pg/nls_pt_br.tgz Please apply. = Euler Taveira de Oliveira euler[at]yahoo_com_br

Re: [PATCHES] Win32 open items

2004-10-30 Thread Bruce Momjian
Magnus Hagander wrote: > >We don't need the cancelConnLock if this is done properly (at least, > >assuming that storing a pointer is atomic, which seems reasonable). > > Are you sure about this? > Per what docs I have, storing a pointer should always be atomic. > exchanging two pointers are not, w