On 2/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
How easy/hard would it be to create unique indexes on tinterval (unique
here meaning non-overlapping) ?
Overlapping is not an equality relation (it fails the transitive law),
so I'm not entirely sure what
Hi,
we've made mistake and initdb database cluster in wrong locale :-(
Now it's full of data. I've read in the docs that it's not possible to
change locale.
But I guess something like this would work:
a)
1) drop all indexes on text/varchar columns
2) change cluster locale
3) create all
On Sat, Feb 17, 2007 at 08:40:54PM +0100, Magnus Hagander wrote:
IIRC, there was a warning from pg_dump. I don't recall exactly what, and
don't have the space to re-run the test on my laptop here, but I think
it was from:
write_msg(modulename, WARNING: ftell mismatch with expected position
I notice that this patch:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h.diff?r1=1.443r2=1.444
inserts a bunch of XML related rows in pg_proc without specifying oid.
This breaks the fmgrtab generator on msvc. Most likely because I didn't
think of that case. But
Tom Lane wrote:
I realized that I can probably fix ATAddForeignKeyConstraint to do the
right thing by having it pass the two actual column types to
can_coerce_type, thus allowing check_generic_type_consistency to kick
in and detect the problem.
Yeah, I came to the same conclusion. No amount of
On Mon, Feb 19, 2007 at 09:27:06AM +0100, Jakub Ouhrabka wrote:
But I guess something like this would work:
a)
1) drop all indexes on text/varchar columns
2) change cluster locale
3) create all indexes on text/varchar columns
You're going to miss the name columns, ie. every string index in
Hello,
On Sat, 17 Feb 2007 06:49:42 -0800 (PST)
RPK [EMAIL PROTECTED] wrote:
PostgreSQL, already a mature database, needs to have more options for
recovery as compared to proprietary databases. I just worked with Oracle's
FlashBack query feature in Oracle 9i and FlashBack Table feature in
Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
This breaks the fmgrtab generator on msvc. Most likely because I didn't
think of that case. But since all other rows in pg_proc.h contain the
oid, I just wanted to check if they're actually supposed to be withuot
oid, or if that was a
On 2/19/07, Oleg Bartunov oleg@sai.msu.su wrote:
pg_trgm was developed for spelling corrrection and there is a threshold of
similarity, which is 0.3 by default. Readme explains what does it means.
Yes, I read it.
Similarity could be very low, since you didn't make separate column and length
I had intended to make varlenas alignment 'c' and have the heaptuple.c force
them to alignment 'i' if they required it. However I've noticed a problem that
makes me think I should do this the other way around.
The problem is that other places in the codebase use the alignment. In
particular
Hi list,
Here's a proposal of this idea which stole a good part of my night.
I'll present first the idea, then 2 use cases where to read some rational and
few details. Please note I won't be able to participate in any development
effort associated with this idea, may such a thing happen!
The
On 17/02/07, Warren Turkal [EMAIL PROTECTED] wrote:
PERIOD(INT) is actually listed in the Dr. Snodgrass's book. However, I am not
really sure about the semantics of the type. When would you use a
PERIOD(INT)?
It wouldn't be directly useful for temporal SQL, but I have a number
of tables in a
On Mon, Feb 19, 2007 at 11:25:02AM +0100, Peter Eisentraut wrote:
Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
This breaks the fmgrtab generator on msvc. Most likely because I didn't
think of that case. But since all other rows in pg_proc.h contain the
oid, I just wanted to
One option that I've heard before is to have vacuum after a single iteration
(ie, after it fills maintenance_work_mem and does the index cleanup and the
second heap pass), remember where it was and pick up from that point next
time.
From my experience this is not acceptable... I have tables
On Mon, Feb 19, 2007 at 11:25:41AM +0100, Dimitri Fontaine wrote:
Hi list,
Here's a proposal of this idea which stole a good part of my night.
I'll present first the idea, then 2 use cases where to read some rational and
few details. Please note I won't be able to participate in any
Bruce Momjian wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Feb 08, 2007 at 01:54:13PM -0500, Tom Lane wrote:
I would be satisfied if the returned command tag were something else,
maybe NO OPERATION.
TABLE blah DID NOT EXIST might be less confusing...
Ühel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
What does/did the row Clustered/replication solutions refer to ?
--
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
What does/did the row Clustered/replication solutions refer
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
However, they don't have vacuum, we do.
Right, and I think that is more or less because Oracle doesn't need
it.
Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
I don't understand -- what problem you got with NO OPERATION? It
seemed a sound idea to me.
It seems nonorthogonal. What if only some of the tables you mentioned did not
exist? Do you get SOME OPERATION?
There are also other cases
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
To get a flashback query, you just have to construct a snapshot from
that time and you are done. We don't store
Florian G. Pflug escribió:
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
To get a flashback query, you just have to construct a snapshot from
that time and
Well this is certainly interesting. What do we think it
would take to
enable the functionality?
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something
First we must run the query in serializable mode and replace the
snapshot with a synthetic one, which defines visibility at the
start
of the desired transaction
probably it is a good idea to take a lock on all tables involved to
avoid a vacuum to be started on them when the query
Zeugswetter Andreas ADI SD wrote:
First we must run the query in serializable mode and replace the
snapshot with a synthetic one, which defines visibility at the
start
of the desired transaction
probably it is a good idea to take a lock on all tables involved to
avoid a vacuum to be
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
I don't understand -- what problem you got with NO OPERATION? It
seemed a sound idea to me.
It seems nonorthogonal. What if only some of the tables you mentioned did
not
exist? Do you
On Mon, 19 Feb 2007, Guillaume Smet wrote:
On 2/19/07, Oleg Bartunov oleg@sai.msu.su wrote:
pg_trgm was developed for spelling corrrection and there is a threshold of
similarity, which is 0.3 by default. Readme explains what does it means.
Yes, I read it.
Similarity could be very low, since
On Sat, Feb 17, 2007 at 01:28:22PM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I'd also like a comment from at least one other patch reviewer that
the methods used are good.
It looks reasonable as far as it goes. One thought is that pg_dump
really should have noticed
Dawid Kuroczko [EMAIL PROTECTED] writes:
... Now, assuming UNIQUE INDEX on such table, the order would be preserved
since no two intervals can overlap. And no overlapping data could be inserted
without breaking ovelapivity. And of course non-unique index would
produce garbage (since left
On 2/19/07, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
I don't understand -- what problem you got with NO OPERATION? It
seemed a sound idea to me.
It seems nonorthogonal. What if only some of the
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that controls global xmin.
It would ensure, that
Martijn van Oosterhout kleptog@svana.org writes:
But I guess something like this would work:
1) drop all indexes on text/varchar columns
2) change cluster locale
3) create all indexes on text/varchar columns
You're going to miss the name columns, ie. every string index in
pg_catalog.
But
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
This breaks the fmgrtab generator on msvc. Most likely because I didn't
think of that case. But since all other rows in pg_proc.h contain the
oid, I just wanted to check if they're actually
Gregory Stark [EMAIL PROTECTED] writes:
Once this is done it may be worth having arrays convert to short varlenas as
well.
Elements of arrays are not subject to being toasted by themselves, so
I don't think you can make that work. At least not without breaking
wide swaths of code that works
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good implementations already exist for us to sit on top of.
regards, tom lane
Am Montag, 19. Februar 2007 16:26 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
This breaks the fmgrtab generator on msvc. Most likely because I didn't
think of that case. But since all other rows in pg_proc.h contain
Am Montag, 19. Februar 2007 15:57 schrieb Tom Lane:
The precedent that I'm thinking about is that the command tag for COMMIT
varies depending on what it actually did.
Some have also argued against that in the past, so I guess we just have
different ideas of how it should work. Not a problem.
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 16:26 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
This breaks the fmgrtab generator on msvc.
It's intentional.
Kindly change that intention.
On 2/19/07, Oleg Bartunov oleg@sai.msu.su wrote:
You need to wait GiN support.
OK. Thanks.
If you need testers for this one, feel free to contact me. I'm very
interested in testing pg_trgm in conjunction with tsearch2.
--
Guillaume
---(end of
Tom Lane [EMAIL PROTECTED] writes:
In the second place, if you don't want to predetermine OIDs for your
functions then they shouldn't be in hardwired pg_proc.h rows at all.
Is there any place to hook in to create things like procedures or other SQL
objects that don't really need hard coded
Le lundi 19 février 2007 16:33, Tom Lane a écrit :
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good implementations already exist for us to
Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
Well, in the first place Gen_fmgrtab.sh is producing garbage:
Uh, ok, that needs fixing.
In the second place, if you don't want to predetermine OIDs for your
functions then they shouldn't be in hardwired pg_proc.h rows at all.
Where else
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
In the second place, if you don't want to predetermine OIDs for your
functions then they shouldn't be in hardwired pg_proc.h rows at all.
Where else would you put them?
SQL script maybe, much along
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 19, 2007 at 04:00:09PM +0100, Florian G. Pflug wrote:
[...]
In the long run, you'd probably want to store the commit-times of
transactions somewhere, and add some guc that makes a vacuum assume
that recently comitted transaction (say,
Dimitri Fontaine [EMAIL PROTECTED] writes:
You're both saying RAID/LVM implementations provide good enough performances
for PG not having to go this way, if I understand correctly.
There's certainly no evidence to suggest that reimplementing them
ourselves would be a productive use of our
On Mon, Feb 19, 2007 at 05:10:36PM +0100, Dimitri Fontaine wrote:
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good implementations already exist for us to sit on top of.
I though moving some knowledge about data availability into PostgreSQL code
Peter Eisentraut wrote:
Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
Well, in the first place Gen_fmgrtab.sh is producing garbage:
Uh, ok, that needs fixing.
In the second place, if you don't want to predetermine OIDs for your
functions then they shouldn't be in hardwired
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
I don't understand -- what problem you got with NO OPERATION? It
seemed a sound idea to me.
It seems nonorthogonal. What if only some of the tables you mentioned did
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I'd suggest that the text is changed to something along the line of:
database system was interrupted while in recovery at ...
If this has occurred more than once some data may be corrupted and
you may need to restore from the last
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Guillaume Smet escribió:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
So add the session ID (%c) to log_line_prefix.
It could work if log_line_prefix was added before every line but it's
definitely not the case:
myuser mydb
Guillaume Smet escribió:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Guillaume Smet escribió:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
So add the session ID (%c) to log_line_prefix.
It could work if log_line_prefix was added before every line but it's
definitely not
Hi,
I started working again on my
IDENTITY/GENERATED patch.
My question is $SUBJECT.
This code is in rewriteTargetlist():
new_attr = build_column_default()
new_tle = makeTargetEntry((Expr *) new_expr, ...)
Now, in ExecInsert() I have to compute
the default for IDENTITY/GENERATED
between
On Mon, Feb 19, 2007 at 01:28:46PM +0100, Lukas Kahwe Smith wrote:
Hannu Krosing wrote:
Ãhel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
If it adds necessary context then it clear does not have the same
behavior,
I mean log_line_prefix behaviour is the same. The other information
are syslog specific.
I'd propose adding a log_entry_prefix separate from log_line_prefix; the
Tom Lane wrote:
SQL script maybe, much along the lines Greg was just mentioning.
I would welcome that, although a similar suggestion was rejected a few
years ago, which is why I didn't pursue it here.
you can't just decide to leave out a few OIDs on the
spur of the moment.
I still don't
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those
wheels when perfectly good implementations already exist for us to
sit on top of.
I expect that
Peter Eisentraut wrote:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those
wheels when perfectly good implementations already exist for us to
sit on top
Peter Eisentraut wrote:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those
wheels when perfectly good implementations already exist for us to
sit on top
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Once this is done it may be worth having arrays convert to short varlenas as
well.
Elements of arrays are not subject to being toasted by themselves, so
I don't think you can make that work. At least not without
Gregory Stark wrote:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that controls global xmin.
It
On Mon, 19 Feb 2007, Guillaume Smet wrote:
Why not simply put something like %log_table% in the sql file and let
the admin replace it with sed or whatever he likes?
This is a reasonable approach. I would suggest that no special characters
be used though, so that the SQL could be used as-is
Magnus Hagander wrote:
Windows supports both RAID and LVM.
Oh good, so we've got that on record. :)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by
August Zajonc wrote:
Gregory Stark wrote:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that
Stefan Kaltenbrunner wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those
wheels when perfectly good implementations already
On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get more
details? I guess I need to see exactly what locks
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good implementations already exist for
Andrew Sullivan wrote:
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good
On Mon, 19 Feb 2007, Joshua D. Drake wrote:
Longer than that... it supported mirroring and raid 5 in NT4 and
possibly even NT3.51 IIRC.
Mirroring and RAID 5 go back to Windows NT 3.1 Advanced Server in 1993:
http://support.microsoft.com/kb/114779
http://www.byte.com/art/9404/sec8/art7.htm
Added to TODO:
* Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause
http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php
Joshua D. Drake wrote:
Andrew Sullivan wrote:
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when
On Mon, 19 Feb 2007 20:30:59 +0100, Florian G. Pflug [EMAIL PROTECTED]
said:
August Zajonc wrote:
Gregory Stark wrote:
Couldn't you define things simply to be that you get a consistent view
including all transactions started before x transaction? This is time
travel lite, but low
On Mon, 19 Feb 2007, Alvaro Herrera wrote:
We already have a combined GUC option that is used to change two
different things (DateStyle) and I regularly see people confused about
how to use it.
You already have a combined GUC option called log_destination that's
sitting in the appropriate
Andrew Sullivan wrote:
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good
Added to TODO:
* Allow UPDATEs on only non-referential integrity columns not to
conflict
with referential integrity locks
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php
Added to TODO:
* Consider allowing configuration of TOAST thresholds
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php
---
Simon Riggs wrote:
On Mon, 2007-02-05 at 19:18 -0500, Jan Wieck wrote:
On
I have updated the PQfree documentation; patch attached. Backpatched
to 8.2.X.
---
Zeugswetter Andreas ADI SD wrote:
future for some reason. (the doc for the other functions say you
have to
use PQfreemem without
Hi Tom,
Hacking pg_control would be the hard part; you'll never get the CRC
right if you do it manually. Possibly pg_resetxlog could be adapted
to the purpose.
thanks for your valuable answer! I looked at pg_resetxlog.c but I'm no
pg internals' expert - would something like this work?
1)
On Mon, 2007-02-19 at 19:38 +, Simon Riggs wrote:
On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get
Added to developer's FAQ:
PIsrc/Makefile.custom/I can be used to set environment variables,
like ICUSTOM_COPT/I, that are used for every compile.
---
Magnus Hagander wrote:
If we did what you suggest, then
On Sun, 2007-02-18 at 18:19 -0500, Tom Lane wrote:
While thinking about having a centralized plan cache for managing plan
invalidation, I got annoyed again about the fact that the executor needs
access to the Query tree. This means that we'll be storing *three*
representations of any cached
Simon Riggs [EMAIL PROTECTED] writes:
After looking over the code it seems that the executor needs a limited
subset of the Query fields, namely
...
which I think we should put into a new TopPlan node type.
All else sounds good, but why would we be caching a plan that used these
fields?
Um,
Pavel Stehule wrote:
Hello,
I miss doc for this operator
Strang IS [NOT] OF wasn't documented, especially seeing it was added in
PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
Bruce Momjian wrote:
Pavel Stehule wrote:
Hello,
I miss doc for this operator
Strang IS [NOT] OF wasn't documented, especially seeing it was added in
PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
Here's the reason -- see this thread:
Joe Conway wrote:
Bruce Momjian wrote:
Pavel Stehule wrote:
Hello,
I miss doc for this operator
Strang IS [NOT] OF wasn't documented, especially seeing it was added in
PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
Here's the reason -- see this thread:
Gregory Stark wrote:
If we could have autovacuum interrupt a vacuum in mid-sweep, perform a cycle
of vacuums on smaller tables, then resume, that problem would go away. That
sounds too difficult though, but perhaps we could do something nearly as good.
I think to make vacuum has this
On Mon, Feb 19, 2007 at 02:50:34PM -0500, Andrew Sullivan wrote:
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about
Greg Smith [EMAIL PROTECTED] writes:
A workable syntax might be
INSERT INTO pg_log ...
Why is this still under discussion? I thought we'd agreed that COPY
format was the way to go.
regards, tom lane
---(end of
August Zajonc [EMAIL PROTECTED] writes:
The key is how lightweight the setup could be, which matters because
clients are not always willing to pay for a PITR setup. The low overhead
would mean you'd feel fine about setting guc to 1hr or so.
This would have exactly the same performance
I am still waiting for a plpython patch that has Python version
checking.
---
Guido Goldstein wrote:
Peter Eisentraut wrote:
Guido Goldstein wrote:
Is it possible to tell me which python versions you want to
support?
I have a WIP patch that adds the main detail I have found I need to
properly tune checkpoint and background writer activity. I think it's
almost ready to submit (you can see the current patch against 8.2 at
http://www.westnet.com/~gsmith/content/postgresql/patch-checkpoint.txt )
after making
I think I'll go with Tom's Plan B for HEAD, but not do anything more for
8.2 than has already been done.
cheers
andrew
Bruce Momjian wrote:
Did we come to a conclusion on this?
---
Andrew Dunstan wrote:
Andrew
Greg Smith [EMAIL PROTECTED] writes:
On Mon, 19 Feb 2007, Alvaro Herrera wrote:
Also, sql is not really a destination -- it is a format.
A log file with a different name is another destination. eventlog is
certainly a different format and it's sitting happily as an option there.
I haven't
On Mon, 19 Feb 2007, Tom Lane wrote:
Why is this still under discussion? I thought we'd agreed that COPY
format was the way to go.
Joshua Drake said COPY would be a good option, but INSERT is probably
what I would use as the default. The most use I see for this is something
where I am
On 2/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
My understanding is that the main difference is that rollbacks are
inexpensive for us, but expensive for Oracle.
Yes, Oracle is optimized for COMMIT, we're optimized for ROLLBACK :)
In all seriousness, last time I checked Oracle's MVCC was
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Elements of arrays are not subject to being toasted by themselves, so
I don't think you can make that work. At least not without breaking
wide swaths of code that works fine today.
You think it's more likely there
Greg Smith [EMAIL PROTECTED] writes:
The arguments for COPY are performance and that you don't need to specify
the table name. INSERT is slower and you need a name, but it's easier to
build a UNIX tool style pipeline to import it in real-time.
I can't believe that any production situation
On Sat, 2007-02-17 at 12:48 -0500, Tom Lane wrote:
Relcache inval casts a fairly wide net; for example, adding or dropping an
index will invalidate all plans using the index's table whether or not
they used that particular index, and I believe that VACUUM will also
result in a relcache inval
On Monday 19 February 2007 15:08, Bruce Momjian wrote:
Joshua D. Drake wrote:
Andrew Sullivan wrote:
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Somehow this seems like implementing RAID within postgres,
RAID and LVM
Reposting - looks like the message did not get through in the first
attempt. My apologies if multiple copies are received.
This is the next version of the HOT WIP patch. Since the last patch that
I sent out, I have implemented the HOT-update chain pruning mechanism.
When following a HOT-update
On Monday 19 February 2007 11:27, Martijn van Oosterhout wrote:
On Mon, Feb 19, 2007 at 05:10:36PM +0100, Dimitri Fontaine wrote:
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good implementations already exist for us to sit on top
of.
I though
1 - 100 of 105 matches
Mail list logo
