Hi,
On Thu, Jul 20, 2006 at 02:36:53PM +0200, moises wrote:
For example Inserts, Update, delete, etc.
If you need a storage for structured data, database servers are good to
go. If you need a very fast flow of not-so-needed and
okay-to-miss-we-can-regenerate type of data storage you can go with
Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
18% in s_lock is definitely bad :-(. Were you able to determine which
LWLock(s) are accounting for the contention?
Sorry for the delay. Finally I got the oprofile data. It's
huge(34MB). If you are interested, I can put
Bandicoot is currently failing on HEAD with the following error shown in
a message box during make check:
---
postgres.exe - Entry Point Not Found
---
The procedure entry point ldap_start_tls_sA could not be located in the
dynamic link library
Robert Lor wrote:
I've have attached a patch along with two new files.This patch should
reflect what we discussed at the Summit. Please let me know if I miss
anything.
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
1) The
Hi All I am looking for a C/C++ library which can talk to postgresql/postgis other than libpqxx!!thanx in advancesandeep
On Fri, Jul 21, 2006 at 01:42:26PM +0200, Peter Eisentraut wrote:
Robert Lor wrote:
I've have attached a patch along with two new files.This patch should
reflect what we discussed at the Summit. Please let me know if I miss
anything.
I would prefer to drop the PG_ prefixes on PG_TRACE
On Jul 20, 2006, at 8:49 PM, Joshua D. Drake wrote:
It could be interesting to have something like this:
./configure --with-plruby
and it would actually fetch the latest plruby sources from the net
and build. Ala Ports.
Or if we didn't want to develop that infastructure of
On Thu, 2006-07-20 at 15:41 -0400, Tom Lane wrote:
Usage of a partitioned hash table would then be like
compute hashtable lookup key;
entryhashcode = calc_hash(lookup key);
partitionnumber = entryhashcode % NumPartitions;
On Thu, Jul 13, 2006 at 07:17:31PM -0400, Tom Lane wrote:
There has been talk of attaching a search_path setting to each function
so that it's independent of the caller's search_path, but the
performance hit seems a bit daunting. In any case it's not pg_dump's
fault that this feature doesn't
Ühel kenal päeval, R, 2006-07-21 kell 17:14, kirjutas Sandeep
Jakkaraju(Navolve):
Hi All
I am looking for a C/C++ library which can talk to postgresql/postgis
other than libpqxx!!
Why ?
thanx in advance
sandeep
--
Hannu Krosing
Database Architect
Skype Technologies
On Wed, Jul 19, 2006 at 07:54:49PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Indeed, if I find a case where there's a large enough number of rows it
will choose the smaller index. But I'm wondering if it would be better
to always favor the smaller index, since it would
Thanks for your answer,
I have experience with
postgres and I know perfectly that not a TOY.
But some concepts of real
time system dont based only in speed.
Real time databases needs
some other kinds of semantics and features that postgres dont have.
Postgres dont supports real
Robert Lor [EMAIL PROTECTED] writes:
I ran pgbench and fired up a DTrace script using the lwlock probes we've
added, and it looks like BufMappingLock is the most contended lock, but
CheckpointStartLocks are held for longer duration!
Those numbers look a bit suspicious --- I'd expect to see
On Wed, Jul 19, 2006 at 07:45:24PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
ISTM that as soon as vacuum dirties a page, it might as well update all
tuples it can (any where Xmin GetOldestXmin()), since that won't take
much time compared to the cost of writing the page
Time units is easy:
1h = 60min = 3600s = 360ms
We don't need anything larger than seconds at the moment.
Except for log_rotation_age perhaps?
-- Korry
Real time databases needs some other kinds of semantics and
features that postgres don't have.
Postgres don't supports real time constrains semantics in
transactions. In other hands the concurrent transactions
don't wok well based on priorities of task.
The program scheduler of
Ühel kenal päeval, R, 2006-07-21 kell 08:29, kirjutas Jim C. Nasby:
No, this is 8.1.3, and it's a production machine so I'd prefer not to go
about dropping indexes to get cost comparisons; unless there's some way
to disable the use of an index in a given backend?
Currently the closest thing
Jim C. Nasby [EMAIL PROTECTED] writes:
For clobbering xmin too early, we could make it so that only tuples
older than some threashold would be subject to 'early freezing'.
OK, that might be acceptable.
One
possibility is that early freeze is at 1B transactions and we push
forced-freeze back
On Thu, Jul 20, 2006 at 08:46:13PM -0400, Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I'm liking this too. But when you say jointree node, are you saying to
model the new node type after NestLoop/MergeJoin/HashJoin nodes? These
are referred to as join nodes in ExecInitNode. Or as
Jim C. Nasby [EMAIL PROTECTED] writes:
No, this is 8.1.3, and it's a production machine so I'd prefer not to go
about dropping indexes to get cost comparisons; unless there's some way
to disable the use of an index in a given backend?
The traditional hack for that is
begin;
On Fri, Jul 21, 2006 at 09:38:41AM +0200, moises wrote:
I want to know, in a hypothetical server, how many transaction postgres
support for a first approximation.
I found this data of MySQL and DB4o data bases but I can´t find any of
Postgres.
I think you're asking the wrong question. I
Dave Page dpage@vale-housing.co.uk writes:
Bandicoot is currently failing on HEAD with the following error shown in
a message box during make check:
The procedure entry point ldap_start_tls_sA could not be located in the
dynamic link library wldap32.dll.
Just guessing from the function
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 21 July 2006 15:20
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] BF Failure on Bandicoot
Dave Page dpage@vale-housing.co.uk writes:
Bandicoot is currently failing on HEAD with the
Martijn van Oosterhout kleptog@svana.org writes:
On Fri, Jul 21, 2006 at 01:42:26PM +0200, Peter Eisentraut wrote:
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
I don't know. trace is a fairly generic word, how do you know that
On Fri, Jul 21, 2006 at 01:42:26PM +0200, Peter Eisentraut wrote:
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
I don't know. "trace" is a fairly generic word, how do you know
On Fri, Jul 21, 2006 at 12:56:56AM -0700, Robert Lor wrote:
I ran pgbench and fired up a DTrace script using the lwlock probes we've
added, and it looks like BufMappingLock is the most contended lock, but
CheckpointStartLocks are held for longer duration!
Not terribly surprising given that
Hi,
Tom Lane schrieb:
Robert Lor [EMAIL PROTECTED] writes:
I ran pgbench and fired up a DTrace script using the lwlock probes we've
added, and it looks like BufMappingLock is the most contended lock, but
CheckpointStartLocks are held for longer duration!
Those numbers look a bit
korry [EMAIL PROTECTED] writes:
How about the obvious DTRACE( ) or some similar variant?
Because it's supposed to be generic, ie, not strictly tied to DTrace.
(I'm not sure there is any realistic other alternative at the moment,
but that's the idea...)
regards, tom
Peter Eisentraut wrote:
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
I also agree with Martin Tom to keep the PG_ prefixes.
We should probably move the probes file to a subdirectory. Anyone know
a good place?
Also,
korry wrote:
How about the obvious DTRACE( ) or some similar variant?
The idea is to keep the macro name generic since it can be mapped to
other tracing facility on other platforms.
Regards,
-Robert
---(end of broadcast)---
TIP 9: In
We apologize for multiple receipts.
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
On Fri, Jul 14, 2006 at 08:08:11PM +0200, Stefan Kaltenbrunner wrote:
Greg Sabino Mullane wrote:
Doesn't our inclusion of md5() pretty much blow that argument away?
(Just asking).
I don't think so because md5 is just a one way hash function. There
is no method to decrypt anything :).
Robert Lor wrote:
The user needs to have the flexibility to build a 32 bit PG binary
even when he run the 64 bit kernel. If I understand you correctly,
your suggestion will not allow a 32 bit binary to be built on a 64
bit OS.
I'm not sure about the context. How do you control whether the
Sorry to poke - but I'd like to get a patch submitted next week. Any
more comments? Thanks.
-- Korry
Thanks
for the quick feedback.
1) I think the most straightforward way to load an instrumentation
plugin is to define a new custom GUC variable (using the
Gavin, Peter,
I would imagine that Peter intends to handle backward compatibility by
processing values without explicit units in the units assumed pre 8.2.
Aha, I misunderstood.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of
Hello,
Thanks for your answer.
Maybe I asking a wrong question, but I just need some ideas like you say
that posgres can insert 100,000 rows per second, is a good approximation...
In other hand if you visit some links like
http://developer.db4o.com/forums/post/25599.aspx
You will find something
[snip] Suppose that every
body say me that POStgres is to slow for real time databases, then I will be
very full trying to resolve this problems with postgres, don't think that?
I think you didn't understand correctly: postgres is not slow, it is
just not suitable for real RT applications
What you are asking is essentially the equivalent of asking How long is
a piece of string? The question is meaningless and so will be any
answer. The fact that there are web sites which are happy to supply you
with meaningless information doesn't mean we should follow suit.
And frankly, I
Hi Korry,
On Jul 21, 2006, at 12:51 PM, korry wrote:
Sorry to poke - but I'd like to get a patch submitted next week.
Any more comments? Thanks.
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger would work. From previous threads I saw DBGP mentioned
(http://xdebug.org/docs-dbgp.php), but I don't recall seeing any final
commitment to it.
The
korry [EMAIL PROTECTED] writes:
I see no good reason to tie
it to plpgsql; we'll just need another one for every other language.
Hmmm... but the plugins themselves would be language-specific.
You miss my point. The plugins will be language-specific but the
mechanism for selecting/loading
I thought I had successfully added the patch for gin support to my
8.1.4 installation, however I get the error: access method gin does
not exist. There is no record for the gin index in the pg_am
table, which I assume needs to be present. I have restarted
postgres. Is there anything
You need initdb
Oleg
On Fri, 21 Jul 2006, Monica D'Arcy wrote:
I thought I had successfully added the patch for gin support to my 8.1.4
installation, however I get the error: access method gin does not exist.
There is no record for the gin index in the pg_am table, which I assume
needs to be
I forgot to note, that this patch doesn't contains last improvements Teodor
did on Code Sprint - significant speedup of index creation.
Oleg
On Fri, 21 Jul 2006, Monica D'Arcy wrote:
I thought I had successfully added the patch for gin support to my 8.1.4
installation, however I get the
When the plugin's shared library gets loaded, one way or the other,
it should construct the function-pointer struct and then pass it to a
function defined by plpgsql (this lets us hide/postpone the decision
about whether there can be more than one active plugin).
On Tue, Jul 18, 2006 at 03:37:52PM +0300, Marko Kreen wrote:
On 7/14/06, Tom Lane [EMAIL PROTECTED] wrote:
I don't see a strong need for moving pgcrypto into core, and there's at
least one argument against it: if someone needs a crypto-free version of
postgres for use someplace with benighted
Ühel kenal päeval, R, 2006-07-21 kell 13:29, kirjutas Andrew Dunstan:
What you are asking is essentially the equivalent of asking How long is
a piece of string? The question is meaningless and so will be any
answer. The fact that there are web sites which are happy to supply you
with
So I would like either some mention of the more useful/stable modules
in core docs or a way for contrib modules to become 'official' add-on
modules (like PL-s are).
This is actually an issue that goes way beyond pgcrypto. I think the
manual should formally mention both /contrib and
Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-21 kell 13:29, kirjutas Andrew Dunstan:
What you are asking is essentially the equivalent of asking How long is
a piece of string? The question is meaningless and so will be any
answer. The fact that there are web sites which are happy to
Hi korry-san.
From: korry
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger would work. From previous threads I saw DBGP mentioned
(http://xdebug.org/docs-dbgp.php), but I don't recall
The documentation [1] says this about On-line backup and point-in-
time recovery:
If we continuously feed the series of WAL files to another machine
that has been loaded with the same base backup file, we have a hot
standby system: at any point we can bring up the second machine
and it
Is this possible today in a stable and robust way? If so, can we
document the procedure? If not, should we alter the documentation so
it's not misleading? I've had several people ask me where to enable the
hot standby feature, not realizing that PostgreSQL only has some of
the raw materials
Tom Lane wrote:
Ah, I finally realize why Magnus wanted to add a --bindir option to
pg_regress: there's no other way to cope with testing a relocated
installation. Seems better to call it --psqldir though, since the
only thing we need to find in that case is psql.
Well, if the ecpg tests
Peter Eisentraut wrote:
Tom Lane wrote:
Ah, I finally realize why Magnus wanted to add a --bindir option to
pg_regress: there's no other way to cope with testing a relocated
installation. Seems better to call it --psqldir though, since the
only thing we need to find in that case is psql.
On Thursday 20 July 2006 18:16, Ron Mayer wrote:
Peter Eisentraut wrote:
I think it would be useful to allow units to be added to these settings,
for example...
shared_buffers = 512MB
which is a bit cumbersome to calculate right now (you'd need = 65536).
I haven't thought yet how to
The cygwin buildfarm is failing:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=eeldt=2006-07-21%2015:00:01
initdb failed
Examine ./log/initdb.log for the reason.
initdb.log is empty, but a dialog box pops up saying:
initdb.exe - Unable To Locate DLL
The dynamic link library cygpq.dll could
Tom Lane wrote:
Also, it'd be interesting to count time spent holding shared lock
separately from time spent holding exclusive.
Tom,
Here is the break down between exclusive shared LWLocks. Do the
numbers look reasonable to you?
Regards,
-Robert
bash-3.00# time ./Tom_lwlock_acquire.d
Peter Eisentraut wrote:
Robert Lor wrote:
The user needs to have the flexibility to build a 32 bit PG binary
even when he run the 64 bit kernel. If I understand you correctly,
your suggestion will not allow a 32 bit binary to be built on a 64
bit OS.
I'm not sure about the context.
Peter, I'll test the patch on Solaris. Thanks!
Regards,
-Robert
Peter Eisentraut wrote:
Here is a consolidated patch that contains all the files. I made some
configure and makefile adjustments and put standard comment headers in
all the files. You can use DTRACEFLAGS to pass options to
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Tom Lane wrote:
Ah, I finally realize why Magnus wanted to add a --bindir option to
pg_regress: there's no other way to cope with testing a relocated
installation. Seems better to call it --psqldir though, since the
only thing
60 matches
Mail list logo