Perhaps because P4 is already doing H/W prefetching?
http://www.tomshardware.com/2000/11/20/intel/page5.html
I ran the test program on an opteron 2.2G:
% ./a.out 10 16
Sum: -951304192: with prefetch on - duration: 81.166 ms
Sum: -951304192: with prefetch off - duration: 79.769 ms
Sum: -951304192
""Luke Lonergan"" <[EMAIL PROTECTED]> wrote
>
>> /* prefetch ahead */
>> __asm__ __volatile__ (
>> "1: prefetchnta 128(%0)\n"
>> :
Qingqing,
On 12/8/05 8:07 PM, "Qingqing Zhou" <[EMAIL PROTECTED]> wrote:
> /* prefetch ahead */
> __asm__ __volatile__ (
> "1: prefetchnta 128(%0)\n"
>
I found an interesting paper improving index speed by prefetching memory
data to L1/L2 cache here (there is discussion about prefetching disk
data to memory several days ago "ice-breaker thread"):
http://www.cs.cmu.edu/~chensm/papers/index_pf_final.pdf
Also related technique used to speedup memcp
On Fri, Dec 09, 2005 at 12:00:14AM +0200, Hannu Krosing wrote:
> > Along those lines, I've wondered if it makes sense to add more
> > flexibility in how free space is reclaimed in a table. One obvious
> > possibility is to have a strategy where new tuples will always look to
> > the FSM for space (
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Yeah. I really don't understand it, but it appears to me to be explicitly
> different in the spec for on delete cascade even compared to the rest of
> the referential actions.
>> One problem I see is, what do we do if the BEFORE
>> trigger then returns
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Here's another interesting encoding issue. I cannot recall having seen it
> on the lists.
This problem has been mentioned before, eg here
http://archives.postgresql.org/pgsql-hackers/2005-03/msg01004.php
(that whole thread is relevant to the problem).
Bu
Trent Shipley <[EMAIL PROTECTED]> writes:
> Child tables are supposed to be able to over-ride parent constraints.
Says who?
If we allow that, then reading the parent table will produce rows that
violate the parent's constraint. This does not seem very wise.
regards, to
If we're bringing up odd encoding issues, why not talk about the mystery
encoding of the shared catalogs? :)
Basically depending on which database you're logged into when you alter
a catalog will affect what encoding the new object appears as in the
shared catalog.
This for one makes it impo
On Thursday 2005-12-08 15:47, Simon Riggs wrote:
> does of course already exist, so the following should cause dependency
> violation ERRORs:
> - omitting the CASCADE when attempting to delete parent constraint
> - attempting to drop the child constraint
Why should dropping the child constraint f
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I see in that discussion you say:
>> Every rowtype Datum will carry its own concrete type.
> Are we storing that on disk in every composite object?
Yup. For a rowtype datum it's not a serious overhead. I realize
that the same is not true of enums :-
On Thu, 8 Dec 2005, Jan Wieck wrote:
> On 12/7/2005 4:50 PM, Stephan Szabo wrote:
>
> > On Wed, 7 Dec 2005, Bruce Momjian wrote:
> >
> >> I had an open 8.1 item that was:
> >>
> >>o fix foreign trigger timing issue
> >>
> >> Would someone supply text for a TODO entry on this, as I don't think
Hi all,
Here's another interesting encoding issue. I cannot recall having seen it
on the lists.
---
[EMAIL PROTECTED] build7]$ bin/createdb -E LATIN1 test
CREATE DATABASE
[EMAIL PROTECTED] build7]$ cat break.sh
dat=`echo -en "\245\241"`
echo "create table test (d text);"
echo "insert into test v
On 12/8/05, Bruce Momjian wrote:
> > A script which identifies non-utf-8 characters and provides some
> > context, line numbers, etc, will greatly speed up the process of
> > remedying the situation.
>
> I think the best we can do is the "iconv -c with the diff" idea, which
> is
On Thu, 2005-12-08 at 11:10 +, Simon Riggs wrote:
> On Wed, 2005-12-07 at 21:24 +, Simon Riggs wrote:
> > Following patch implements record of whether a constraint is inherited
> > or not, and prevents dropping of inherited constraints.
>
> Patch posted to -patches list.
>
> > What it doe
Gavin Sherry wrote:
> On Tue, 6 Dec 2005, Bruce Momjian wrote:
>
> >
> > Exactly what does vim do that iconv does not? Fuzzy encoding sounds
> > scary to me.
> >
>
> Right. It actually makes assumptions about the source encoding. People who
> care about their data need, unfortunately, to spend a
On Tue, 6 Dec 2005, Bruce Momjian wrote:
>
> Exactly what does vim do that iconv does not? Fuzzy encoding sounds
> scary to me.
>
Right. It actually makes assumptions about the source encoding. People who
care about their data need, unfortunately, to spend a bit of time on this
problem. I've bee
I have stamped the 8.1.1 CVS tree and it is ready for testing/packaging.
The release notes are here:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1-1
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us |
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Still thinking a bit more about this ... how about we have output
functions take an optional second argument, which is the type oid?
No. We just undid that for good and sufficient security reasons.
If an output function dep
Ühel kenal päeval, N, 2005-12-08 kell 12:57, kirjutas Jim C. Nasby:
> On Thu, Dec 08, 2005 at 11:58:50AM +0200, Hannu Krosing wrote:
> > > > The problem with separate list is that it can be huge. For example on a
> > > > table with 200 inserts/updates per second an index build lasting 6 hours
> >
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Still thinking a bit more about this ... how about we have output
> functions take an optional second argument, which is the type oid?
No. We just undid that for good and sufficient security reasons.
If an output function depends on anything more than
Simon Riggs wrote:
...REINDEX...CREATE/DROP INDEX...
I'm curious if partitioning can help help
provide online create/reindex.
For example, if I could set set up a table
partitioned by "modified time"; could I make
a new partition so all new inserts go into a
new partition and then I can re-ind
True, I think we need hooks for both methods.On 12/8/05, Jan Wieck <[EMAIL PROTECTED]> wrote:
On 12/8/2005 2:05 PM, Jim C. Nasby wrote:> On Thu, Dec 08, 2005 at 08:33:59AM -0800, Darcy Buskermolen wrote:>> On Wednesday 07 December 2005 20:24, Tom Lane wrote:>> > Christopher Kings-Lynne <
[EMAIL PR
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm hand-waving here, so I'll stop. But we do know there *is* a way,
> because this is already implemented elsewhere, somehow.
That's not really the point --- the question is whether the cure is
worse than the disease. It's entirely possible that the trad
On 12/8/2005 2:05 PM, Jim C. Nasby wrote:
On Thu, Dec 08, 2005 at 08:33:59AM -0800, Darcy Buskermolen wrote:
On Wednesday 07 December 2005 20:24, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Anyone remember this patch?
> > http://gorda.di.uminho.pt/community/pgsqlho
A general purpose log miner is also useful
in many other areas besides replication.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jonah H. Harris
Sent: Thursday, December 08, 2005
11:32 AM
To: Jim C. Nasby
Cc: Darcy Buskermolen;
pgsql-hackers@postgresql.org;
On 12/8/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
While this code might be useful, whouldn't it be much more valuable toprovide hooks into xlog so that we could do non-trigger-basedreplication? (As well as non-trigger-based materialized views...)
If we're going to do hooks for replication, I thi
On 12/7/2005 11:24 PM, Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Anyone remember this patch?
http://gorda.di.uminho.pt/community/pgsqlhooks/
The discussion seems to be pretty minimal:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00859.php
Does anyone see a n
On 12/8/2005 1:28 PM, Gustavo Tonini wrote:
Are you sure that no way to implement a generic aproach on the backend? What
You mean "generic" as in a replication system that can do asynchronous
master-slave, asynchronous multimaster with conflict resolution based on
timestamps, system priority
On Thu, Dec 08, 2005 at 01:07:10PM -0500, Tom Lane wrote:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> >> BTW, there's another end to the 'enable_seqscan=false' problem... it
> >> sometimes doesn't work!
>
> > I have often considered that this is an indication that seq scan is
> > actually the b
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> The cleanest solution seems to be to make the bgwriter create and use a
> ResourceOwner, and probably get rid of the special hack in resowner.c
> that allows CurrentResourceOwner to be NULL.
>
Is that true that every moment the bgwriter just has one buffer
On Thu, Dec 08, 2005 at 08:33:59AM -0800, Darcy Buskermolen wrote:
> On Wednesday 07 December 2005 20:24, Tom Lane wrote:
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > > Anyone remember this patch?
> > > http://gorda.di.uminho.pt/community/pgsqlhooks/
> > > The discussion seems to be
What is the point of these questions? If you have a concrete, practical
proposal to make, please do so. Otherwise, you have already got the
answer from the people who are actually working on replication and
understand it far beyond abstract considerations. If you think there is
a good reason
On 12/8/2005 1:42 PM, Jim C. Nasby wrote:
On Thu, Dec 08, 2005 at 10:03:43AM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > This seems like a useful feature to add, allowing for eas
On Thu, Dec 08, 2005 at 11:58:50AM +0200, Hannu Krosing wrote:
> ??hel kenal p??eval, N, 2005-12-08 kell 01:08, kirjutas Jim C. Nasby:
> > On Thu, Dec 08, 2005 at 08:57:42AM +0200, Hannu Krosing wrote:
> > > ??hel kenal p??eval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
> > > > On Sat, Dec 0
On Thu, Dec 08, 2005 at 10:03:43AM -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > > This seems like a useful feature to add, allowing for easy built-in
> > > > verticle partitioni
Are you sure that no way to implement a generic aproach on the backend?
What does specification say? Does Oracle 10g have a core implementation
of replication (cluster)?
Gustavo.
2005/12/7, Andrew Sullivan <[EMAIL PROTECTED]>:
On Tue, Dec 06, 2005 at 12:35:43AM -0500, Jan Wieck wrote:> We do not p
On Thu, 2005-12-08 at 16:23 +0100, Csaba Nagy wrote:
> On Thu, 2005-12-08 at 16:05, Tom Lane wrote:
> [SNIP]
> > There isn't any way for it to do that (ie, be sure everyone else has
> > adjusted to the new state of affairs), short of acquiring some sort of
> > short-term exclusive lock on the table
On Thu, 2005-12-08 at 10:26 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > The imbalance across partitions would be a major issue because of the
> > difficulty of selecting a well-distributed partitioning key. If you use
> > the LOCKTAG, then operations on the heaviest hit tab
Jaime Casanova <[EMAIL PROTECTED]> writes:
>> BTW, there's another end to the 'enable_seqscan=false' problem... it
>> sometimes doesn't work!
> I have often considered that this is an indication that seq scan is
> actually the better plan...
There are cases where it is the *only* plan, eg, you ha
I think that bug #2099
http://archives.postgresql.org/pgsql-bugs/2005-12/msg00075.php
is probably explained by the observation that the bgwriter fails to call
AtEOXact_Files() after an error; therefore, if it gets an error while
holding an open DIR pointer, the DIR will never get closed. (There ar
> Another nice (but no doubt more complex) thing would be ability to add
> multiple constraints at once, needing only one seqscan to check for
> compliance with added constraints and/or making constraint checks
> smarter, so that for.ex. "ADD CONSTRAINT CHECK i > 0" could make use of
> index on i i
Greg Stark <[EMAIL PROTECTED]> writes:
> Hm, so hypothetically an insert or update on a table with 4 indexes which have
> been split into 4 partitions would need to touch each partition?
That would be the best case, actually, that each heavily-used lock ends
up in a different partition. As Simon
>
> BTW, there's another end to the 'enable_seqscan=false' problem... it
> sometimes doesn't work! Last I looked, enable_seqscan=false only added a
> fixed overhead cost to a seqscan (100 IIRC). The problem is, some
> queries will produce estimates for other methodes that are more
> expensive t
Tom Lane <[EMAIL PROTECTED]> writes:
> That's a fair point, and reinforces my instinct that having a large
> number of partitions would be a losing game. But you are mistaken to
> think that the number of hot-spot tables is the only limit on the number
> of usable partitions. It's the number of
Ühel kenal päeval, N, 2005-12-08 kell 11:10, kirjutas Simon Riggs:
> On Wed, 2005-12-07 at 21:24 +, Simon Riggs wrote:
> > Following patch implements record of whether a constraint is inherited
> > or not, and prevents dropping of inherited constraints.
>
> Patch posted to -patches list.
>
>
> Subject: Re: [HACKERS] forced to restart postgresql service yesterday
>
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > The login was hanging in a simple plpgsql login script which
basically
> > did an insert/update on a small table. It would hang when called
from
> > within psql, and once h
On 12/7/2005 4:50 PM, Stephan Szabo wrote:
On Wed, 7 Dec 2005, Bruce Momjian wrote:
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Would someone supply text for a TODO entry on this, as I don't think we
fixed it in 8.1.
I'd split this into two separate items n
On 12/7/2005 9:37 AM, Devrim GUNDUZ wrote:
Hi,
I'd like to inform the people who does not read Planet PostgreSQL
Command Prompt Inc.has just hired me for my community work I have been
doing so far, like PostgreSQL RPM stuff and other PostgreSQL related
RPMs, such as Slony-I, pgpool, PostGIS, e
On Wednesday 07 December 2005 20:24, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Anyone remember this patch?
> > http://gorda.di.uminho.pt/community/pgsqlhooks/
> > The discussion seems to be pretty minimal:
> > http://archives.postgresql.org/pgsql-hackers/2005-06/msg0
On Thu, 2005-12-08 at 16:05, Tom Lane wrote:
[SNIP]
> There isn't any way for it to do that (ie, be sure everyone else has
> adjusted to the new state of affairs), short of acquiring some sort of
> short-term exclusive lock on the table, which is a really bad idea.
> The pending lock would block ot
Simon Riggs <[EMAIL PROTECTED]> writes:
> The imbalance across partitions would be a major issue because of the
> difficulty of selecting a well-distributed partitioning key. If you use
> the LOCKTAG, then operations on the heaviest hit tables would go to the
> same partitions continually for LockR
Simon Riggs <[EMAIL PROTECTED]> writes:
> Further thoughts:
> 1. Normally, we do not lock indexes via the LockMgrLock
> 2. When a REINDEX-like operation comes along, it first of all updates an
> MaintIntentLock flag on the index relation, which causes a relcache
> invalidation. It then waits until
Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > This seems like a useful feature to add, allowing for easy built-in
> > > verticle partitioning. Are there issues with the patch as-is?
> >
> > Other than the ones m
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The login was hanging in a simple plpgsql login script which basically
> did an insert/update on a small table. It would hang when called from
> within psql, and once hung the query would not respond to cancel
> requests (such as they are implemented
Simon Riggs <[EMAIL PROTECTED]> writes:
> The output you gave wasn't anything I recognize in the code. Assuming
> its not already there, please can you share code you are using to find
> the evidence, even if its just privately in some form?
See below. Also, the message I previously mentioned sho
Yesterday one of our clients called up and complained about lousy
performance and being unable to log in to our postgresql 8.0 backed ERP
running on windows 2000 server. The server has been run for several
months without being restarted or rebooted.
The login was hanging in a simple plpgsql login
I can only add that patched code did not build on windows, contacted author
about that and never got an answer back.
Regards
paolo
Tom Lane <[EMAIL PROTECTED]> ha scritto
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Anyone remember this patch?
> > http://gorda.di.uminho.pt/community
On Wed, 2005-12-07 at 21:24 +, Simon Riggs wrote:
> Following patch implements record of whether a constraint is inherited
> or not, and prevents dropping of inherited constraints.
Patch posted to -patches list.
> What it doesn't do:
> It doesn't yet prevent dropping the parent constraint, wh
On Wed, 2005-12-07 at 19:36, Greg Stark wrote:
[snip]
> We periodically ran into problems with load spikes or other performance
> problems causing things to get very slow and stay slow for a while. Letting
> things settle out usually worked but occasionally we had to restart the whole
> system to c
Ühel kenal päeval, N, 2005-12-08 kell 01:08, kirjutas Jim C. Nasby:
> On Thu, Dec 08, 2005 at 08:57:42AM +0200, Hannu Krosing wrote:
> > ??hel kenal p??eval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
> > > On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
> > > > Tom Lane <[EMAIL P
On Wed, 2005-12-07 at 22:53 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > My view would be that the LockMgrLock is not relevant for all workloads,
> > but I want even more to be able to discuss whether it is, or is not, on
> > an accepted basis before discussions begin.
>
>
On Wed, 2005-12-07 at 22:46 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Is hashtable overhead all that large? Each table could be made
> > initially size-of-current-table/N entries. One problem is that
> > currently the memory freed from a hashtable is not put back int
On Thu, 2005-12-01 at 21:37 -0500, Tom Lane wrote:
> In looking at the current pgbench results, I notice that one
> considerable contribution to LWLock contention is access to the
> heavyweight-lock manager.
> 4. The only reason we need to take relation-level locks on indexes
> at all is to make
Hello all,
Thank you for having the interest.
Jim C. Nasby wrote:
> Valid point. I do think there's a lot of benefit to being able to set
> the limit much lower than what it currently defaults to today. We have a
> client that has a queue-type table that is updated very frequently. One
> of the f
65 matches
Mail list logo
