> So what is the state-of-the-art in the Postgresql world if I _do_ want
> synchronous replication? 2-phase commit from the client application? Any
> success/horror stories about doing it in Java?
For Java, you could check out Sequoia (http://sequoia.continuent.org/) or
their commercial version un
PostgreSQL users,
Given the importance of India to the world of software, it's critical that
we have an Indian Regional Contact who can be the community press
relations person for India. In the past, we had Vishal and Shridhar who
did a terrific job but are no longer available.
If you are an
On Mon, 2007-11-26 at 17:37 -0600, Wes wrote:
> On 11/13/07 10:02 AM, "Scott Ribe" <[EMAIL PROTECTED]> wrote:
>
> > What you're referring to must be that the kernel was essentially
> > single-threaded, with a single "kernel-funnel" lock. (Because the OS
> > certainly supported threads, and it was
On Mon, 2007-11-26 at 16:01 -0800, Alex Vinogradovs wrote:
> I've got a data warehouse with pretty high rate of insert into
> partitioned tables. What I've noticed, is that rule-based partitioning
> seems to be somewhat slower than insertions made directly into
> partitions through execution of dy
Hi all,
I've got a data warehouse with pretty high rate of insert into
partitioned tables. What I've noticed, is that rule-based partitioning
seems to be somewhat slower than insertions made directly into
partitions through execution of dynamic SQL.
Is it really true ?
Thanks!
Best regards,
On 11/13/07 10:02 AM, "Scott Ribe" <[EMAIL PROTECTED]> wrote:
> What you're referring to must be that the kernel was essentially
> single-threaded, with a single "kernel-funnel" lock. (Because the OS
> certainly supported threads, and it was certainly possible to write
> highly-threaded applicatio
Tom Hart wrote:
Martin Gainty wrote:
2 things
tr_tran_time needs to be already in 'time format'
is_ok needs to be indexed (preferably bitmapped index)
HTH/
Martin
The data is COPY'ed from csv's that our internal software creates, and
we don't have control over output format. Is coaxing tr_t
Martin Gainty wrote:
2 things
tr_tran_time needs to be already in 'time format'
is_ok needs to be indexed (preferably bitmapped index)
HTH/
Martin
The data is COPY'ed from csv's that our internal software creates, and
we don't have control over output format. Is coaxing tr_tran_time into
pr
2 things
tr_tran_time needs to be already in 'time format'
is_ok needs to be indexed (preferably bitmapped index)
HTH/
Martin
- Original Message -
From: "Tom Hart" <[EMAIL PROTECTED]>
To: "Postgres General List"
Sent: Monday, November 26, 2007 5:30 PM
Subject: [GENERAL] speed up insert qu
Hey everybody. I'm trying to speed up a query (not general optimization,
one query in particular), and I'm not sure if there's any way to get it
to go faster.
The query looks like this
INSERT INTO transaction
(
"tr_acct_num",
"tr_acct_typ",
"tr_atm_rec",
"tr_audit_seq",
"tr_branch_cd",
"
On Nov 26, 2007, at 3:21 PM, Chris Browne wrote:
[EMAIL PROTECTED] (Erik Jones) writes:
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
It's
[EMAIL PROTECTED] (Glyn Astill) writes:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
Well, a "modal approach" is possible - that's what Postgres-R tries to
do.
Of course
[EMAIL PROTECTED] (Erik Jones) writes:
> Since no one's mentioned it, and while I don't have any personal
> experience with it, I thought I'd mention the recently released
> Bucardo (http://bucardo.org/) as another Postgres replication option.
It's Yet Another Asynchronous Replication System, ergo
On Nov 26, 2007 1:11 PM, Steve Crawford <[EMAIL PROTECTED]> wrote:
> It's worse than that.
>
> If we presume that the plate is a key to a vehicle, then we immediately
> run into problems as a vehicle can, over time, have several plates
> (lost, stolen, changed to vanity...) and a plate can belong,
On Nov 26, 2007 3:41 PM, Garber, Mikhail <[EMAIL PROTECTED]> wrote:
>
> So what is the state-of-the-art in the Postgresql world if I _do_ want
> synchronous replication? 2-phase commit from the client application? Any
> success/horror stories about doing it in Java?
Depending on the restrictions
So what is the state-of-the-art in the Postgresql world if I _do_ want
synchronous replication? 2-phase commit from the client application? Any
success/horror stories about doing it in Java?
---(end of broadcast)---
TIP 6: explain analyze is your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/07 12:11, Steve Crawford wrote:
[snip]
>
> If we presume that the plate is a key to a vehicle, then we immediately
> run into problems as a vehicle can, over time, have several plates
> (lost, stolen, changed to vanity...) and a plate can bel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 12:39:42 -0500
Chris Browne <[EMAIL PROTECTED]> wrote:
> Unfortunately, the only way to make things deterministic (or to get
> from "near real time" to "*GUARANTEED* real time") is to jump to
> synchronous replication, which is no
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
Erik Jones
Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.
Joshua D. Drake wrote:
> On Mon, 26 Nov 2007 10:28:03 -0800 (PST)
> Richard Broersma Jr <[EMAIL PROTECTED]> wrote:
>> --- On Mon, 11/26/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>>> In "theory" the item that would be a natural key
>>> in this instance is the VIN.
And you then need to deal wi
Madison Kelly wrote:
> Hi all,
>
> What is the proper syntax/escape character when using 'ALTER ... OWNER TO
> user-name'? I've tried single quotes, backslashes, backticks and various
> others without luck. Is it at all possible?
Double quotes (same as for any identifier)
--
Alvaro Herrera
Hi all,
What is the proper syntax/escape character when using 'ALTER ...
OWNER TO user-name'? I've tried single quotes, backslashes, backticks
and various others without luck. Is it at all possible?
Thanks!
Madi
---(end of broadcast)---
TIP
On Mon, Nov 26, 2007 at 03:31:46PM +0100, Thomas Kellerer wrote:
>
> "EnterpriseDB Replication Server replicates data across the enterprise
> in near real time to meet a wide array of business challenges. Data can
Slony does this, except that it can't talk to Oracle. What's wrong with
Slony?
On Mon, Nov 26, 2007 at 07:25:04AM -0600, Jeff Larsen wrote:
>
> My 2 cents...
>
> I would rather see someone working on true synchronous replication,
It will cost more than US$0.02. But if you're willing to put up real money,
there are people willing to put in the work. Or, if you're willing
On Mon, Nov 26, 2007 at 07:02:35PM +, Glyn Astill wrote:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
This is what Postgres-R is intended to do. In order to get that
On Nov 26, 2007 1:30 PM, Steve Crawford <[EMAIL PROTECTED]> wrote:
> I'm sure someone has defined a "vehicle", but I don't know what number
> applies when you've pieced together a rebuilt engine, salvaged
> transmission, junkyard hood and so-on to get a working car. I think
> custom builders end u
Joshua D. Drake wrote:
In "theory" the item that would be a natural key in this instance is
the VIN. You would of course have to make some kind of allowance for
cars that don't have a VIN (nothing in the last what... 50 years?).
And some kind of allowance for Title 49, Sec. 565.4, subsection (d)
On Nov 26, 2007 1:02 PM, Glyn Astill <[EMAIL PROTECTED]> wrote:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
Ummm, if one server falls behind, and the other keeps going,
> It's worse than that.
It's even worse than that. Decades ago, Florida used to issue multiple
plates with the same number, differentiated by color.
There are other cases of states having multiple types of license plates,
with overlapping numbers.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.kil
Okay I'm relaxed ;-) honest.
It does irritate me sometimes (my fault) when people post back
comments as if they have knowledge on a subject when they don't
though, if you don't know then keep quiet.
All it does is confuse prople like me, who really don't know, and are
reaching out for a little h
> --- Original Message ---
> From: Chris Browne <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: 26/11/07, 17:39:42
> Subject: Re: [GENERAL] replication in Postgres
>
> I believe that what they are using is a version of Slony-I, which
> certainly falls into the "near real t
Glyn Astill escribió:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
Guess what, Postgres-R is designed to do that.
> Just for the record I'm a programmer, not a database
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
I'm just interested.
Of course a grid or a clustwer is better to makesure all servers are
in sync, but there's performance issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 18:57:19 + (GMT)
Glyn Astill <[EMAIL PROTECTED]> wrote:
>
> --- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Glyn Astill wrote:
> > > Thanks everyone for your replies. EnterpriseDB looks like the way
> > to
> > > go if we
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Glyn Astill wrote:
> > Thanks everyone for your replies. EnterpriseDB looks like the way
> to
> > go if we want good replication.
>
> Sorry, this makes no sense to me -- EnterpriseDB has no replication
> solution that I know of.
>
This is bullsh*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 10:28:03 -0800 (PST)
Richard Broersma Jr <[EMAIL PROTECTED]> wrote:
> --- On Mon, 11/26/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > In "theory" the item that would be a natural key
> > in this instance is the VIN. You wou
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Richard Broersma Jr
> Sent: Monday, November 26, 2007 10:28 AM
> To: Joshua D. Drake
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Primary Key
>
> --- On Mon, 11/26/07, Joshua D. Drake <
--- On Mon, 11/26/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> In "theory" the item that would be a natural key
> in this instance is the VIN. You would of course have
> to make some kind of allowance for cars that don't
> have a VIN (nothing in the last what...
> 50 years?).
So this is why t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 10:11:37 -0800
Steve Crawford <[EMAIL PROTECTED]> wrote:
> Although I haven't seen it much, recently, semi-trucks used to
> regularly have with numerous plates - one for each state in which
> they operated. And some states such as
[EMAIL PROTECTED] ("Jeff Larsen") writes:
>> Alvaro Herrera wrote:
>> > Glyn Astill wrote:
>> >> Thanks everyone for your replies. EnterpriseDB looks like the way to
>> >> go if we want good replication.
>> >
>> > Sorry, this makes no sense to me -- EnterpriseDB has no replication
>> > solution tha
Martijn van Oosterhout wrote:
On Fri, Nov 23, 2007 at 09:33:13AM +, Peter Childs wrote:
I tend to agree that primary keys should be single fields if they need to be
referenced but should also be natural if at all possible. ie use car number
plates rather than some serial int.
Car n
Jeff Larsen wrote:
Alvaro Herrera wrote:
Glyn Astill wrote:
Yes, but I'd like something better than "near real time" as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money.
Well do what EnterpriseDB does :) use Slony. Which i
> > Yes, but I'd like something better than "near real time" as the above
> > page describes. Or maybe someone could clarify that Besides,
> > EnterpriseDB does not save me enough money. In my current commercial
> > DB, if a transaction is committed on the master, it is guaranteed to
> > be com
On Nov 26, 2007, at 10:14 AM, Jeff Larsen wrote:
Yes, but I'd like something better than "near real time" as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money. In my current commercial
DB, if a transaction is committed on the m
On Nov 24, 2007, at 6:18 PM, Laurent CARON wrote:
Question:
I'd like to know if it is possible (and wise) to just keep the
/var/lib/postgres.. directories from the old 32Bit server to use
on
the 64Bit version.
This is just as a personal interest since I can also just dump and
restore th
> Alvaro Herrera wrote:
> > Glyn Astill wrote:
> >> Thanks everyone for your replies. EnterpriseDB looks like the way to
> >> go if we want good replication.
> >
> > Sorry, this makes no sense to me -- EnterpriseDB has no replication
> > solution that I know of.
>
> Yeah, there is:
>
> http://www.e
Alvaro Herrera wrote:
> Glyn Astill wrote:
>> Thanks everyone for your replies. EnterpriseDB looks like the way to
>> go if we want good replication.
>
> Sorry, this makes no sense to me -- EnterpriseDB has no replication
> solution that I know of.
Yeah, there is:
http://www.enterprisedb.com/pro
Alvaro Herrera, 26.11.2007 15:07:
EnterpriseDB has no replication solution that I know of.
Quote from
http://www.enterprisedb.com/products/enterprisedb_replication.do
"EnterpriseDB Replication Server replicates data across the enterprise
in near real time to meet a wide array of business chal
On Mon, 2007-11-26 at 07:25 -0600, Jeff Larsen wrote:
> > Someone is working on extending the current system to allow read-only
> > queries on a standby server [1], thus making it a "hot standby", but
> > this feature apparently won't be included until 8.4 [2].
>
> My 2 cents...
>
> I would rathe
Glyn Astill wrote:
> Thanks everyone for your replies. EnterpriseDB looks like the way to
> go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
> Postgres-r sounds very nice but moving our organisations data onto a
> system
Jeff Larsen escribió:
> > Someone is working on extending the current system to allow read-only
> > queries on a standby server [1], thus making it a "hot standby", but
> > this feature apparently won't be included until 8.4 [2].
>
> My 2 cents...
>
> I would rather see someone working on true sy
> Someone is working on extending the current system to allow read-only
> queries on a standby server [1], thus making it a "hot standby", but
> this feature apparently won't be included until 8.4 [2].
My 2 cents...
I would rather see someone working on true synchronous replication,
rather than a
52 matches
Mail list logo
