Surely such a use case could, and more to the point *should* be met
using PITR?
Regards,
- Naz.
Alvaro Herrera wrote:
A.M. wrote:
On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
[2] Nobody else has this, I believe, exc
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> As far as I know, we asked for a libpq API change and you ignored
>> multiple requests. You want the URLs?
No. One suggestion was made regarding an internal technical issue (polling
versus using select/poll on the sockets). I've long ago made that
Bruce Momjian wrote:
> Gregory Stark wrote:
> >
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >
> > > They could roll their own a lot easier if you had finished the psql
> > > concurrent patch.
> >
> > I did. But you decided you didn't want it.
>
> As far as I know, we asked for a libpq API
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > They could roll their own a lot easier if you had finished the psql
> > concurrent patch.
>
> I did. But you decided you didn't want it.
As far as I know, we asked for a libpq API change and you ignored
multiple requests
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> They could roll their own a lot easier if you had finished the psql
> concurrent patch.
I did. But you decided you didn't want it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Matthew T. O'Connor wrote:
> >> Bruce Momjian wrote:
> >> >
> >> > * Allow multiple indexes to be created concurrently, ideally via a
> >> > single heap scan, and have a restore of a pg_dump somehow use it
>
> Actually, t
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Matthew T. O'Connor wrote:
>> Bruce Momjian wrote:
>> >
>> > * Allow multiple indexes to be created concurrently, ideally via a
>> > single heap scan, and have a restore of a pg_dump somehow use it
Actually, the sync scan patch ought to make this m
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Allow multiple indexes to be created concurrently, ideally via a
> > single heap scan, and have a restore of a pg_dump somehow use it
> >
> > http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php
>
>
Bruce Momjian wrote:
Added to TODO:
* Allow multiple indexes to be created concurrently, ideally via a
single heap scan, and have a restore of a pg_dump somehow use it
http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php
Would it not also make sense to use this ability for a
Added to TODO:
* Allow multiple indexes to be created concurrently, ideally via a
single heap scan, and have a restore of a pg_dump somehow use it
http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php
---
Tom Lane wrote:
> Right. Multiple seqscans that are anywhere near reading the same block
> of a table will tend to self-synchronize. There is a patch under
> consideration for 8.3 that helps this along by making seqscans run
> "circularly" --- that is, not always from block 0 to block N, but from
Scott Ribe <[EMAIL PROTECTED]> writes:
>> So it works right now, except it doesn't have (yet) the infrastructure to
>> keep the scans synchronized
> Perhaps you only got one read of the table because the process is
> essentially self-synchronizing.
Right. Multiple seqscans that are anywhere near
I believe you have made quite a good description of what happens.
Index-building isn't very CPU-intensive for integers (geometrics and
tsearch is another matter, of course), so building all indexes of a large
table in one pass is a possibility that works now, provided you issue all
> So it works right now, except it doesn't have (yet) the infrastructure to
> keep the scans synchronized
Perhaps you only got one read of the table because the process is
essentially self-synchronizing. Whenever one process "gets ahead", it
requires a disk read for the next page, which causes it
On 06/01/07 11:22, Bruce Momjian wrote:
> PFC wrote:
>> On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <[EMAIL PROTECTED]> wrote:
>>
>>> On May 25, 2007, at 5:28 PM, Tom Lane wrote:
>>>
That's true at the level of DDL operations, but AFAIK we could
parallelize table-loading and inde
On Sat, 02 Jun 2007 00:14:28 +0200, Ron Johnson <[EMAIL PROTECTED]>
wrote:
On 06/01/07 16:38, PFC wrote:
Will the synchronized seq scan patch be able to do this by
issuing all the CREATE INDEX commands at the same time from several
different database connections ?
No, but it coul
On 06/01/07 16:38, PFC wrote:
Will the synchronized seq scan patch be able to do this by
issuing all the CREATE INDEX commands at the same time from several
different database connections ?
No, but it could someday.
Actually I tested, it does it right now, albeit unconsciously (p
Will the synchronized seq scan patch be able to do this by issuing
all the CREATE INDEX commands at the same time from several different
database connections ?
No, but it could someday.
Actually I tested, it does it right now, albeit unconsciously (pg doesn't
do anything to synchron
On 06/01/07 11:22, Bruce Momjian wrote:
PFC wrote:
On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <[EMAIL PROTECTED]> wrote:
On May 25, 2007, at 5:28 PM, Tom Lane wrote:
That's true at the level of DDL operations, but AFAIK we could
parallelize table-loading and index-creation steps pretty
PFC wrote:
> On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> >
> > On May 25, 2007, at 5:28 PM, Tom Lane wrote:
> >
> >> That's true at the level of DDL operations, but AFAIK we could
> >> parallelize table-loading and index-creation steps pretty effectively
> >> ---
On Thu, 31 May 2007 23:36:32 +0200, PFC <[EMAIL PROTECTED]> wrote:
On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <[EMAIL PROTECTED]> wrote:
On May 25, 2007, at 5:28 PM, Tom Lane wrote:
That's true at the level of DDL operations, but AFAIK we could
parallelize table-loading and index-creat
On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <[EMAIL PROTECTED]> wrote:
On May 25, 2007, at 5:28 PM, Tom Lane wrote:
That's true at the level of DDL operations, but AFAIK we could
parallelize table-loading and index-creation steps pretty effectively
--- and that's where all the time goes.
On May 25, 2007, at 5:28 PM, Tom Lane wrote:
That's true at the level of DDL operations, but AFAIK we could
parallelize table-loading and index-creation steps pretty effectively
--- and that's where all the time goes.
I would be happy with parallel builds of the indexes of a given
table. T
On Sat, May 26, 2007 at 02:33:05PM -0400, Tom Lane wrote:
> making userids be [EMAIL PROTECTED] not just a username). This is probably
> why
> they still haven't got IPv6 support:
> http://bugs.mysql.com/bug.php?id=8836
> I wonder what their plans are for fixing that ...
Panic at the last second
At 03:25 AM 5/25/2007, A.M. wrote:
Indeed. Wouldn't it be a cool feature to persists transaction states
across connections so that a new connection could get access to a
sub- transaction state? That way, you could make your schema changes and
test them with any number of test clients (which de
MySQL has a related problem, which is that they have embedded IPv4
addressing rather deeply into their client authentication logic (by
making userids be [EMAIL PROTECTED] not just a username). This is probably why
they still haven't got IPv6 support:
http://bugs.mysql.com/bug.php?id=8836
I won
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> A more interesting question is what sort of hardware you need for that
>>> actually to be a win, though. Loading a few tables in parallel sounds
>>> like an ideal recipe for oversaturating your disk bandwidth
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Harpreet Dhaliwal írta:
>> is the host base configuration methodology in postgres superior to
>> other RDBMS.
> If you ask me, yes. When I had to choose between MySQL 3.x and
> PostgreSQL 6.5 a long ago and I was able to exclude the DB superuser
>
Zoltan Boszormenyi írta:
If you ask me, yes. When I had to choose between MySQL 3.x and
PostgreSQL 6.5 a long ago and I was able to exclude the DB superuser
with REVOKE CONNECT from MySQL, I said "no, thanks".
I did it on purpose to prove that you can the external configuration
is better in this
If you ask me, yes. When I had to choose between MySQL 3.x and
PostgreSQL 6.5 a long ago and I was able to exclude the DB superuser
with REVOKE CONNECT from MySQL, I said "no, thanks".
I did it on purpose to prove that you can the external configuration
is better in this case.
And apart from fixi
is the host base configuration methodology in postgres superior to other
RDBMS.
is this something novel that postgres has come up with?
~Harpreet
On 5/26/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A more interesting question is
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A more interesting question is what sort of hardware you need for that
>> actually to be a win, though. Loading a few tables in parallel sounds
>> like an ideal recipe for oversaturating your disk bandwidth...
> you don't actua
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Erik Jones wrote:
>>> And, to finish up, is there any reason that pg_restore couldn't
>>> already work with separate processes working in parallel?
>
>> The problem is that the ordering of objects in the dump is the only
>> thing th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 23:02, Chris Browne wrote:
> [EMAIL PROTECTED] (Alvaro Herrera) writes:
>> Erik Jones wrote:
>>
>>> And, to finish up, is there any reason that pg_restore couldn't
>>> already work with separate processes working in parallel?
>> The probl
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Erik Jones wrote:
>
>> And, to finish up, is there any reason that pg_restore couldn't
>> already work with separate processes working in parallel?
>
> The problem is that the ordering of objects in the dump is the only
> thing that makes the dump cons
On Fri, May 25, 2007 at 05:28:43PM -0400, Tom Lane wrote:
> That's true at the level of DDL operations, but AFAIK we could
> parallelize table-loading and index-creation steps pretty effectively
> --- and that's where all the time goes.
I made a presentation at OSCON a few years ago about how we d
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Erik Jones wrote:
>> And, to finish up, is there any reason that pg_restore couldn't
>> already work with separate processes working in parallel?
> The problem is that the ordering of objects in the dump is the only
> thing that makes the dump consist
Erik Jones wrote:
> And, to finish up, is there any reason that pg_restore couldn't
> already work with separate processes working in parallel?
The problem is that the ordering of objects in the dump is the only
thing that makes the dump consistent with regards to the dependencies of
objects.
On May 25, 2007, at 11:36 AM, Chris Browne wrote:
[EMAIL PROTECTED] (Erik Jones) writes:
On May 24, 2007, at 5:21 PM, Chris Browne wrote:
Jan Wieck had a proposal to a similar effect, namely to give some
way
to get one connection to duplicate the state of another one.
This would permit doin
On Fri, May 25, 2007 at 01:26:02PM -0500, Ron Johnson wrote:
> >> 1. transaction failure on statement failure[0], and
> >
> > I personally regard that as a feature, not a bug, so I'd be opposed
> > to changing it.
>
> Why? Not failing the whole transaction lets me decide how to handle
> that *on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 13:09, Andrew Sullivan wrote:
> On Fri, May 25, 2007 at 12:59:25PM -0500, Ron Johnson wrote:
>> Except that seemingly "boutique" features can be road-blocks to
>> implementing projects, which means that you never hear from them.
>
> Yes.
On Fri, May 25, 2007 at 12:59:25PM -0500, Ron Johnson wrote:
> Except that seemingly "boutique" features can be road-blocks to
> implementing projects, which means that you never hear from them.
Yes. That's a risk that free software projects take, alas. If you
can't force your users to tell you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 12:18, Andrew Sullivan wrote:
> On Fri, May 25, 2007 at 12:36:20PM -0400, Chris Browne wrote:
>> We seem to be suffering, as the community, and patch queue, grows,
>> from the problem that features that are regarded as being useful only
>>
On Fri, May 25, 2007 at 12:36:20PM -0400, Chris Browne wrote:
> We seem to be suffering, as the community, and patch queue, grows,
> from the problem that features that are regarded as being useful only
> to small sets of users are seeing greater reluctance for acceptance.
Another way of expressin
[EMAIL PROTECTED] (Erik Jones) writes:
> On May 24, 2007, at 5:21 PM, Chris Browne wrote:
>> Jan Wieck had a proposal to a similar effect, namely to give some way
>> to get one connection to duplicate the state of another one.
>>
>> This would permit doing a neat parallel decomposition of pg_dump:
On May 24, 2007, at 5:21 PM, Chris Browne wrote:
[EMAIL PROTECTED] ("A.M.") writes:
On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
[2] Nobody else has this, I believe, except possibly Ingres and
NonStop SQL. This means you can do a "
I think the general topic got lost in the weeds there...
But it would be helpful if you identified what you care about in a
database. That drives a lot of these decisions.
Example: My brother uses MySQL and I use Postgresql.
His reasons for MySQL:
More books on it at the bookstore.
It was a
On May 24, 2007, at 20:39 , Andrew Sullivan wrote:
On Thu, May 24, 2007 at 03:25:52PM -0400, A.M. wrote:
Wouldn't it be a cool feature to persists transaction states
across connections so that a new connection could get access to a
sub-
transaction state?
You could do this using an incred
On Thu, May 24, 2007 at 03:25:52PM -0400, A.M. wrote:
> Wouldn't it be a cool feature to persists transaction states
> across connections so that a new connection could get access to a sub-
> transaction state?
You could do this using an incredibly evil, carefully implemented
hack in a connect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/07 17:21, Chris Browne wrote:
[snip]
>
> This would permit doing a neat parallel decomposition of pg_dump: you
> could do a 4-way parallelization of it that would function something
> like the following:
>
> - connection 1 opens, establishes
On May 24, 2007, at 18:21 , Chris Browne wrote:
Jan Wieck had a proposal to a similar effect, namely to give some way
to get one connection to duplicate the state of another one.
This would permit doing a neat parallel decomposition of pg_dump: you
could do a 4-way parallelization of it that w
Chris Browne wrote:
> [EMAIL PROTECTED] ("A.M.") writes:
> Jan Wieck had a proposal to a similar effect, namely to give some way
> to get one connection to duplicate the state of another one.
>
> This would permit doing a neat parallel decomposition of pg_dump: you
> could do a 4-way parallelizat
Alexander Staubo wrote on 24.05.2007 17:30:
[2] Nobody else has this, I believe, except possibly Ingres and
NonStop SQL. This means you can do a "begin transaction", then issue
"create table", "alter table", etc. ad nauseum, and in the mean time
concurrent transactions will just work. Beautiful f
[EMAIL PROTECTED] ("A.M.") writes:
> On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
>
>> On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
>>
>>> [2] Nobody else has this, I believe, except possibly Ingres and
>>> NonStop SQL. This means you can do a "begin transaction", then issue
>>> "cre
On May 24, 2007, at 18:12 , PFC wrote:
Indeed. Wouldn't it be a cool feature to persists transaction states
across connections so that a new connection could get access to a
sub-
transaction state? That way, you could make your schema changes and
test them with any number of test clients (
Indeed. Wouldn't it be a cool feature to persists transaction states
across connections so that a new connection could get access to a sub-
transaction state? That way, you could make your schema changes and
test them with any number of test clients (which designate the state
to connect with) an
We're derailing the thread, but...
On 5/24/07, A.M. <[EMAIL PROTECTED]> wrote:
2PC requires that the modifications already be in concrete. What I
suggest is a method for a new connection to insert itself into an
existing (sub-)transaction SQL stream, make changes, and commit to
the root or paren
On May 24, 2007, at 15:57 , Alvaro Herrera wrote:
A.M. wrote:
Indeed. Wouldn't it be a cool feature to persists transaction states
across connections so that a new connection could get access to a
sub-
transaction state? That way, you could make your schema changes and
test them with any n
A.M. wrote:
>
> On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
>
> >On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
> >
> >>[2] Nobody else has this, I believe, except possibly Ingres and
> >>NonStop SQL. This means you can do a "begin transaction", then issue
> >>"create table", "alter
On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
[2] Nobody else has this, I believe, except possibly Ingres and
NonStop SQL. This means you can do a "begin transaction", then issue
"create table", "alter table", etc. ad nauseum, and in
On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
> [2] Nobody else has this, I believe, except possibly Ingres and
> NonStop SQL. This means you can do a "begin transaction", then issue
> "create table", "alter table", etc. ad nauseum, and in the mean time
> concurrent transactions will just
On Thursday 24. May 2007 19:57, Erik Jones wrote:
>On May 24, 2007, at 4:39 AM, Richard Huxton wrote:
>> - unpronounceable name
>
>post-gres-queue-el
Somebody probably wants to put that pot-grass-kewl thing in his pipe and
smoke it.
--
Leif Biberg Kristensen | Registered Linux User #338009
http:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/07 12:48, Alexander Staubo wrote:
> On 5/24/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
>> > [2] Nobody else has this, I believe, except possibly Ingres and
>> > NonStop SQL. This means you can do a "begin transaction", then issue
>> > "create
On May 24, 2007, at 4:39 AM, Richard Huxton wrote:
- unpronounceable name
post-gres-queue-el
Erik Jones
Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://
On 5/24/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
> [2] Nobody else has this, I believe, except possibly Ingres and
> NonStop SQL. This means you can do a "begin transaction", then issue
> "create table", "alter table", etc. ad nauseum, and in the mean time
> concurrent transactions will just wo
For us?
Stability. Pure and simple. It ended up that the site was faster too.
One issue with postgresql is that connection time is slower than
mysql. Otherwise most everything else is just as fast or faster.
So with Ruby on Rails, there is a persistent connections from the
container, and that di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/07 10:30, Alexander Staubo wrote:
> On 5/24/07, Richard Huxton <[EMAIL PROTECTED]> wrote:
>> Tom Allison wrote:
>> > You've addressed cost and performance.
>> > Not much left.
>> >
>> > Try it out for yourself and see if it works for you.
>>
>
On 5/24/07, Richard Huxton <[EMAIL PROTECTED]> wrote:
Tom Allison wrote:
> You've addressed cost and performance.
> Not much left.
>
> Try it out for yourself and see if it works for you.
+ elephant in logo
- unpronounceable name
+ excellent mailing lists
+ excellent developer community
- you ca
Better support!
Where else can you get feedback from the actual programmers (sometimes
within minutes of writing a message) than here?
Ben
> Hi
> I was wondering, apart from extensive procedural language support
> and being free,
> what are other major advantages of Postgresql over other major
On Thursday 24 May 2007 10:06, Jasbinder Singh Bali wrote:
> Hi
> I was wondering, apart from extensive procedural language support and being
> free,
> what are other major advantages of Postgresql over other major RDBMS like
> oracle and sql server.
>
> Any pointers would be highly appreciated.
Tom Allison wrote:
You've addressed cost and performance.
Not much left.
Try it out for yourself and see if it works for you.
+ elephant in logo
- unpronounceable name
+ excellent mailing lists
+ excellent developer community
- you can download as many copies as you like and a salesman still w
You've addressed cost and performance.
Not much left.
Try it out for yourself and see if it works for you.
On May 24, 2007, at 4:06 AM, Jasbinder Singh Bali wrote:
Hi
I was wondering, apart from extensive procedural language support
and being free,
what are other major advantages of Postgres
Hi
I was wondering, apart from extensive procedural language support and being
free,
what are other major advantages of Postgresql over other major RDBMS like
oracle and sql server.
Any pointers would be highly appreciated.
Thanks,
~Jas
73 matches
Mail list logo
