On Fri, 2007-04-27 at 07:36 +0200, Pavel Stehule wrote:
> it's true. There is bug. I'll send actualised version tomorrow.
No need: I fixed the bug and applied the patch. Thanks for the patch.
-Neil
Thank you
Pavel
_
Citite se
Arjen van der Meijden told me that according to the tweakers.net
benchmark, HEAD is noticeably slower than 8.2.4, and I soon confirmed
here that for small SELECT queries issued as separate transactions,
there's a significant difference. I think much of the difference stems
from the fact that we no
On Fri, 2007-04-27 at 07:36 +0200, Pavel Stehule wrote:
> it's true. There is bug. I'll send actualised version tomorrow.
No need: I fixed the bug and applied the patch. Thanks for the patch.
-Neil
---(end of broadcast)---
TIP 6: explain analyze
Umm, please define "does not work". You're going to need to give
details about your setup, what you're actually doing and what's going
wrong if you expect any answers...
On Sat, Apr 28, 2007 at 08:56:46PM +0800, shieldy wrote:
> few days before, I said I wanto joinin the postgresql develope group.
On Thu, Apr 12, 2007 at 02:56:24PM -0700, Andrew Hammond wrote:
> I've written the following function definitions to extend
> generate_series to support some temporal types (timestamptz, date and
> time). Please include them if there's sufficient perceived need or
> value.
>
> -- timestamptz versi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I was actually thinking that we could slip this in 8.3. It's a simple,
> well-understood patch, which fixes a little data integrity quirk as well
> as gives a nice recovery speed up.
Yeah. It's arguably a bug fix, in fact, since it eliminates the
my postgresql source code is at c:/mingw/postgresql and instal to
C:/msys/1.0/local/pgsql/
I add a function to src\backend\utils\adt\geo_ops.c as the following:
*Datum
box_add2(PG_FUNCTION_ARGS)
{
BOX *box = PG_GETARG_BOX_P(0);
Point*p = PG_GETARG_POINT_P(1);*
* PG_RETURN_BOX_P(box_constr
few days before, I said I wanto joinin the postgresql develope group. and
recently, I make some progress, such as get throught the base steps. but
when i add some functions to the spatial data, such as box_add1() to box
data, but when I compile it, and install it to my computer, it turns out
,the
On Apr 28, 2007, at 10:30 , Guido Barosio wrote:
Now, my question is: Shouldn't postgresql avoid the creation of the
table while a serial type contains a check condition?
My question to you is why should it? "a" SERIAL is a shorthand for
creating an INTEGER column "a", a sequence ("a_seq
Thanks for your reply Michael.
My point was to step on the asumption that the implicit "serial"
call for a type represents the fact that the sequence will start
allways in the same place, unless inmediatelly after your "create
table" you plan to modify that, which makes no sense when we go back
Hey ya,
Found a behaviour that caught my attention. While it's not a real
problem, and definetely not serious, I realize that it may be good to
write about it, cause I couldn't find previous posts on the matter.
Basically, I am preparing a presentation for an install party, and
while I was ch
Alvaro Herrera wrote:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> Stefan Kaltenbrunner wrote:
two of my buildfarm members had different but pretty weird looking
failures lately:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:
I was actually thinking that we could slip this in 8.3. It's a simple,
well-understood patch, which fixes a little data integrity quirk as well
as gives a nice recovery speed up.
Bruce Momjian wrote:
I assume this is 8.4 material.
--
Simon Riggs wrote:
On Fri, 2007-04-27 at 12:22 +0100, Heikki Linnakangas wrote:
Patch implementing that attached. I named the function "ReadOrZeroBuffer".
We already have an API quirk similar to this: relation extension. It
seems strange to have two different kinds of special case API that are
On Fri, 2007-04-27 at 12:22 +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> As regards the zero_damaged_pages question, I raised that some time ago
> >> but we didn't arrive at an explicit answer. All I would say is we can't
> >> allow invalid p
Cui Shijun wrote:
As the insertion algorithm described, a specific partition lock manage some
items, but these items can be stored in anywhere of the hash table,not
necessarily in a bucket chain.
So there are some problems with "different partitions use different hash
chains",
a partition can use
2007/4/28, Heikki Linnakangas <[EMAIL PROTECTED]>:
3. Lock that partition
6. Unlock partition
I suddenly realize that LW locks are used to manage the lock hash table.So
when a item is to be inserted into hash table, we must gain that partition
lock
first to change that table.
As the insertion
Jim Nasby wrote:
On Apr 27, 2007, at 12:35 PM, Gregory Stark wrote:
The column won't be dropped physically until you execute one of the
commands
that rewrites the table entirely. "CLUSTER" and "ALTER TABLE ALTER
column TYPE
type" are the two popular ones.
UPDATE SET field1 = field1; would al
Insertion algorithm in a nutshell:
1. Calculate hash value
2. Take 4 least-significant bits of the hash value. These tell you which
partition the value belongs to.
3. Lock that partition
4. Take the X (X > 4) least significant bits of the hash value. These
tell you which hash bucket the value
19 matches
Mail list logo
