On Thu, Sep 18, 2003 at 06:53:00PM +0100, Oliver Elphick wrote:
> Line 138 begins the definition of strndup(). However, strndup() is also
> declared in string.h, which is included by this file. If I rename this
> function to estrndup() (and also where it is called, further down) the
> compilation
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> The default_statistics_target was already 1000 for
> postgres7.4beta2 and after setting this value to 1000
> for postgres7.3.3 I had the same explain with the same
> expected row ( almost 400 ) and the almost the same time execution.
Hmph. Can you loo
Carlos Guzman Alvarez <[EMAIL PROTECTED]> writes:
> I'm sending this for array parameters (in binary format):
> * the number of dimensions.
> * flags (always 0).
> * base type of the array elements (oid).
> * lengths and lower bounds.
> * array values.
>
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, it sure looks to be exactly the same plan. The performance
>> difference seems to be just that the seqscans are faster. I surmise
>> that in the 7.3 database you had a lot of dead rows, or at least a lot
>> of free space. Possi
Gaetano Mendola wrote:
Tom Lane wrote:
Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. Possibly you need to vacuum more often
Paulo Scardine wrote:
(B>
(B> There are many interfaces that doesn't support canceling a long query other
(B> than killing the application or killing the backend using the server
(B> operational system.
(B>
(B> I've searched the docs, faqs and list archives; seen a lot of questions but
(B>
Tom Lane wrote:
Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. Possibly you need to vacuum more often to keep down the
amount
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Unfortunately it's the slower one: Intel cpus have a microcode fastpath
> for memcopies that are 8-byte aligned. This fastpath is around 50%
> faster than the manual copy that is used for "misaligned" (i.e. only
> 4-byte aligned) pointers.
Maybe it'd
Hello:
I'm trying to give support to array parameters for sql commands in my
.net data provider for postgres 7.4, i'm sending the same data as i need
for read array field values but i get always the error :
insufficient data left in message
I'm sending this for array parameters (in binary for
Hi,
When analyzing the kernel profile from osdl dbt benchmarks, I noticed
that around 50% of the kernel time is spent in __copy_user_intel.
http://khack.osdl.org/stp/280060/profile/
This function is one of two functions that does the actual memory copy
from/to kernel space to/from user space.
U
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> = Bad news =
> I posted time ago about a slow query:
> SELECT ul.*
> FROM user_logs ul,
> user_data ud,
> class_default cd
> WHERE ul.id_user = ud.id_user AND
>ud.id_class = cd.id_class AND
>cd.id_provider = 39;
I t
"Paulo Scardine" <[EMAIL PROTECTED]> writes:
>> I trust when you say "kill", you really mean "send SIGINT" ...
> I'm sending a SIGTERM. Would SIGINT be more appropriate?
Yes --- that would actually cancel the query, not cause the backend to
shut down.
regards, tom lane
-
Hi all,
my impression on 7.4 performances:
= Good news =
How expected the use of clausole 'IN' with Postgres 7.4beta2
now is really fast ( see the result below )
= Bad news =
I posted time ago about a slow query:
SELECT ul.*
FROM user_logs ul,
user_data ud,
class_defaul
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
> ...
> I trust when you say "kill", you really mean "send SIGINT" ...
> ...
I'm sending a SIGTERM. Would SIGINT be more appropriate?
Thank you,
--
Paulo Scardine
---(end of broadcast)
"Paulo Scardine" <[EMAIL PROTECTED]> writes:
> So I hacked a small pggetpid and pgkillpid C functions, and now I can learn
> the backend's PID, start the query in a new thread, and kill the backend
> using another connection if I want.
I trust when you say "kill", you really mean "send SIGINT" ...
On Thu, 2003-09-18 at 19:25, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Line 138 begins the definition of strndup(). However, strndup() is also
> > declared in string.h, which is included by this file. If I rename this
> > function to estrndup() (and also where it is called,
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Line 138 begins the definition of strndup(). However, strndup() is also
> declared in string.h, which is included by this file. If I rename this
> function to estrndup() (and also where it is called, further down) the
> compilation succeeds.
Hm, is st
Paulo Scardine [mailto:[EMAIL PROTECTED] wrote:
So I hacked a small pggetpid and pgkillpid C functions, and now I can
learn
the backend's PID, start the query in a new thread, and kill the backend
using another connection if I want. Its ugly, I know, but worked
wonderfully
with ODBC, the Delphi de
"luke" <[EMAIL PROTECTED]> writes:
> Which was syntax of authentication packet in protocol
> with pgsql 7.3.4 ?
See
http://www.postgresql.org/docs/7.3/static/protocol.html
especially
http://www.postgresql.org/docs/7.3/static/protocol-message-formats.html
regards, tom lane
System: i386 (Athlon) - Debian GNU/Linux unstable
PostgreSQL 7.4beta3 fails to compile:
i386-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -pipe -fPIC
-I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils
-I../../../../src/include -I/usr/include/tcl8.4
There are many interfaces that doesn't support canceling a long query other
than killing the application or killing the backend using the server
operational system.
I've searched the docs, faqs and list archives; seen a lot of questions but
no answers.
So I hacked a small pggetpid and pgkillpid C
Which was syntax of authentication packet in protocol
with pgsql 7.3.4 ?
Any doc to read ?!
I’m searching inside my docs but…
luke
For the int2col op value I have this table for when the cast returns NULL
value <0
<, <= ,= int2col=null
>,>= in2col is not null
value > 0
<,<= in2col is not null
=,>,>= int2col=null
Im not sure why pg allows me to do a int2col=null and returns nothing
so I am assuming that internally pg just res
Tom Lane wrote:
I think we have two choices: disallow foreign-key references from temp
tables to permanent tables, or take out the optimization of storing
temp table pages in private memory. (That would leave the whole "local
buffer manager" module as dead code, I think.) I'm kinda leaning
toward
24 matches
Mail list logo
