Ah... It seems that a item is calculated its hash value, get the bucket
number from it and insert into that bucket chain. The insertion has
nothing to do with partition number(but Alvaro says which hash is
used depends on the partition number. I haven't really understood
this: how can we get a
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
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
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 pages in the
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
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.
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=quaggadt=2007-04-25%2002:03:03
and
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
to
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)
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
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);*
*
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
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 version
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 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
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
16 matches
Mail list logo