On 2/20/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee:
What do you do, if there are no live tuples on the page ? will this
un-HOTify the root and free all other tuples in HOT chain ?
Yes. The HOT-updated status of the root
On Mon, Feb 19, 2007 at 11:18:36AM -0500, Tom Lane wrote:
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.
Jonah H. Harris [EMAIL PROTECTED] writes:
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 :)
I used to say
Am Dienstag, 20. Februar 2007 02:13 schrieb Bruce Momjian:
Wow, interesting. I do remember that now. Should I revert the
documentation addition and add a comment to gram.y?
I'd say remove the code.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end
Am Dienstag, 20. Februar 2007 09:24 schrieb Magnus Hagander:
Ok. Will do once the entires in pg_proc are changed, so that I can still
build.
It's done.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 5:
Hi,
I started working on my previous patch, encouraged
by the fact that it became a wishlist item for 8.3. :-)
The changes in this version are:
- Refreshed to almost current (5 days old)
CVS version of 8.3 devel
- The original SERIAL pseudo type is left alone,
you _have to_ spell out
I agree that TimeStamp creates an overhead, but I just want to know if an
accidental update happened to a table and this incident got traced three
days after, what facility PGSQL provide to bring the table to its original
condition. You can't wait regretting on why you did not run ROLLBACK before
Am Dienstag, 20. Februar 2007 02:13 schrieb Bruce Momjian:
Wow, interesting. I do remember that now. Should I revert the
documentation addition and add a comment to gram.y?
I'd say remove the code.
Propably nobody use it for inheritancy, but some people (I am too) use it in
polymorphic
RPK wrote:
I agree that TimeStamp creates an overhead, but I just want to know if an
accidental update happened to a table and this incident got traced three
days after, what facility PGSQL provide to bring the table to its original
condition. You can't wait regretting on why you did not run
On Tue, 20 Feb 2007, Tom Lane wrote:
I can't believe that any production situation could tolerate the
overhead of one-commit-per-log-line.
There aren't that many log lines, and a production environment with lots
of commit throughput won't even notice. The installation I work on tuning
does
Simon Riggs wrote:
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
bruce wrote:
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
documentation addition and add a comment to gram.y?
OK, I have votes to remove the code, remove the documentation, and keep
all of it but document its behavior might change in the future.
what code do you want to remove?
I will leave the documentation, but comment it out so it doesn't
Pavel Stehule wrote:
documentation addition and add a comment to gram.y?
OK, I have votes to remove the code, remove the documentation, and keep
all of it but document its behavior might change in the future.
what code do you want to remove?
Peter suggested removing the IS OF code
Pavan Deolasee [EMAIL PROTECTED] writes:
... Yes. The HOT-updated status of the root and all intermediate
tuples is cleared and their respective ctid pointers are made
point to themselves.
Doesn't that destroy the knowledge that they form a tuple chain?
While it might be that no one cares any
Pavan Deolasee wrote:
When following a HOT-update chain from the index fetch, if we notice that
the root tuple is dead and it is HOT-updated, we try to prune the chain to
the smallest possible length. To do that, the share lock is upgraded to an
exclusive lock and the tuple chain is followed
what code do you want to remove?
Peter suggested removing the IS OF code itself.
without compensation you hip lot of people. Time for removing was 4 years
ago.
Regards
Pavel Stehule
_
Citite se osamele? Poznejte nekoho
On 2/20/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
When following a HOT-update chain from the index fetch, if we notice
that
the root tuple is dead and it is HOT-updated, we try to prune the chain
to
the smallest possible length. To do that, the share lock is upgraded
Pavan Deolasee wrote:
On 2/20/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
When following a HOT-update chain from the index fetch, if we notice
that
the root tuple is dead and it is HOT-updated, we try to prune the chain
to
the smallest possible length. To do
Bruce Momjian [EMAIL PROTECTED] writes:
Pavan Deolasee wrote:
When following a HOT-update chain from the index fetch, if we notice that
the root tuple is dead and it is HOT-updated, we try to prune the chain to
the smallest possible length. To do that, the share lock is upgraded to an
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Pavan Deolasee wrote:
When following a HOT-update chain from the index fetch, if we notice that
the root tuple is dead and it is HOT-updated, we try to prune the chain to
the smallest possible length. To do that, the share lock is
On 2/20/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
... Yes. The HOT-updated status of the root and all intermediate
tuples is cleared and their respective ctid pointers are made
point to themselves.
Doesn't that destroy the knowledge that they form a
On 2/20/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Recently dead means still live to somebody, so those tids better not
change either. But I don't think that's what he meant. I'm more
worried about the deadlock possibilities inherent in trying to upgrade a
buffer lock.
On 2/20/07, Gregory Stark [EMAIL PROTECTED] wrote:
I used to say that too but I've since realized it's not really true.
Heh, take a joke man... I was following up on Drake's email :)
But, since you want to discuss your view of the systems openly... I'll
gladly reply :)
It's more like Oracle
Wrong. When Oracle says it's committed, it's committed. No
difference between when, where, and how. In Oracle, the committed
version is *always* the first presented to the user... it takes time
to go back and look at older versions; but why shouldn't that be a bit
slower, it isn't common
Ühel kenal päeval, T, 2007-02-20 kell 10:20, kirjutas Jonah H. Harris:
On 2/20/07, Gregory Stark [EMAIL PROTECTED] wrote:
I used to say that too but I've since realized it's not really true.
Heh, take a joke man... I was following up on Drake's email :)
But, since you want to discuss your
On Mon, Feb 19, 2007 at 07:10:52PM -0800, David Fetter wrote:
Isn't this one of the big use cases for table partitioning?
Sure, but you can't detach that data in the meantime, AFAIK. Maybe
I've missed something.
If I have 10 years of finace data, and I have to keep it all online
all the
Jonah H. Harris [EMAIL PROTECTED] writes:
On 2/20/07, Gregory Stark [EMAIL PROTECTED] wrote:
It's more like Oracle is optimized for data that's committed
long in the past and we're optimized for data that's
been recently updated.
Wrong. When Oracle says it's committed, it's committed. No
Tom Lane wrote:
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
pagila=# select version();
version
-
PostgreSQL 8.2.3 on i386-pc-solaris2.10, compiled by cc -Xa
(1 row)
pagila=# create or replace function test() returns bool as $$ begin set
statement_timeout = 3000;
Robert Treat [EMAIL PROTECTED] writes:
pagila=# create or replace function test() returns bool as $$ begin set
statement_timeout = 3000; perform pg_sleep(4) ; return true; end $$ language
plpgsql;
CREATE FUNCTION
statement_timeout is measured across an entire interactive command, not
On Tue, Feb 20, 2007 at 08:31:45PM +0530, Pavan Deolasee wrote:
I see your point, but as you mentioned do we really care ? The chain
needs to be broken so that the intermediate DEAD tuples can be
vacuumed. We can't vacuum them normally because they could
be a part of live HOT-update chain.
Andrew,
Demanding unlimited undo at some time that is arbitrarilly distant in the
future strikes me as wholly unreasonable.
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
(PostgreSQL, as they
RPK [EMAIL PROTECTED] writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
(PostgreSQL, as they say), must have an optimized way for undoing of at
least a week changes.
You're living in a
On Feb 20, 2007, at 1:40 PM, Tom Lane wrote:
RPK [EMAIL PROTECTED] writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most
advanced database
(PostgreSQL, as they say), must have an optimized way for undoing
of
I'm wondering if we can do one better...
Since what we really care about is I/O responsiveness for the rest of
the system, could we just time how long I/O calls take to complete? I
know that gettimeofday can have a non-trivial overhead, but do we care
that much about it in the case of autovac?
On Tuesday 20 February 2007 12:50, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
pagila=# create or replace function test() returns bool as $$ begin set
statement_timeout = 3000; perform pg_sleep(4) ; return true; end $$
language plpgsql;
CREATE FUNCTION
statement_timeout is
On 2/20/07, Rod Taylor [EMAIL PROTECTED] wrote:
Do 97% of transactions commit because Oracle has slow rollbacks and
developers are working around that performance issue, or because they
really commit?
Again, off-topic, but 97% of all transactions commit according to Jim
Gray and his
On 2/20/07, Hannu Krosing [EMAIL PROTECTED] wrote:
He probably meant longer transactions and several versions visible to
different backends.
Yes, he may have... but I was responding to the statements he made.
but why shouldn't that be a bit slower, it isn't common practice anyway.
Not for
Are we doing this?
---
Joshua D. Drake wrote:
Hello,
With all the recent discussion on contrib modules etc.. I would like to
offer the following suggestion. I am willing to do a good portion of the
work myself and I
Inspired by this thread [1], and in particular by the idea of storing
three numbers (permanent ID, on-disk storage position, display
position) for each column, I spent a little time messing around with a
prototype implementation of column storage positions to see what kind
of difference it would
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
FYI, I added this to the patches queue because I think we decided
full-text indexing should be in the core. If I am wrong, please let me
know.
---
Teodor Sigaev wrote:
We (Oleg and me) are glad to present tsearch in core
Added to TODO:
* Add missing operators for geometric data types
Some geometric types do not have the full suite of geometric
operators,
e.g. box @ point
---
Jim Nasby wrote:
* Add
Bruce Momjian wrote:
FYI, I added this to the patches queue because I think we decided
full-text indexing should be in the core. If I am wrong, please let me
know.
One of the objections I remember to this particular implementation was
that configuration should be done using functions rather
I always felt is was better for us to have server functions that return
schema-specific data rather than require every application to define its
own functions. I realize they are duplicated in pg_dump, but even if we
made an external library that pg_dump could share with applications,
would it
Was this problem addressed?
---
Magnus Hagander wrote:
On Tue, Jan 23, 2007 at 11:39:23AM -0800, Jeremy Drake wrote:
On Tue, 23 Jan 2007, Magnus Hagander wrote:
On Tue, Jan 23, 2007 at 09:31:40AM -0500, Andrew
On Tue, 20 Feb 2007, Alvaro Herrera wrote:
Bruce Momjian wrote:
FYI, I added this to the patches queue because I think we decided
full-text indexing should be in the core. If I am wrong, please let me
know.
One of the objections I remember to this particular implementation was
that
Oleg Bartunov wrote:
On Tue, 20 Feb 2007, Alvaro Herrera wrote:
Bruce Momjian wrote:
FYI, I added this to the patches queue because I think we decided
full-text indexing should be in the core. If I am wrong, please let me
know.
One of the objections I remember to this particular
Added to TODO:
* Increase locking when DROPing objects so dependent objects cannot
get dropped while the DROP operation is happening
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php
---
Tom Lane
Bruce Momjian wrote:
I always felt is was better for us to have server functions that return
schema-specific data rather than require every application to define its
own functions. I realize they are duplicated in pg_dump, but even if we
made an external library that pg_dump could share with
OK, I have made Solaris gcc the same as Linux in Makefile.shlib, patch
attached.
I am not backpatching this. We will get this tested for 8.3.
---
Jignesh K. Shah wrote:
I dont think we solved this.. But I think the way
Added to TODO:
* Consider decreasing the amount of memory used by PrivateRefCount
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php
---
Now we have --with-libxml (and USE_LIBXML constant for #ifdef-s), what
is not absolutely right: XML support is smth that is more general than
using libxml2 library. E.g., some SQL/XML publishing functions (such
as XMLPI) do not deal with libxml2.
Also, in the future more non-libxml functionality
Just as my 2 cents to the proposed idea.
I want to demonstrate that the proposed idea is very relevant for the
performance.
I recently did an migration from PG 8.1 to PG 8.2. During that time I was
dumping the 2TB database with several very wide tables (having ~ 200
columns). And I saw that
On Tuesday 20 February 2007 16:07, Phil Currier wrote:
Another problem relates to upgrades. With tools like pg_migrator now
on pgfoundry, people will eventually expect quick upgrades that don't
require rewriting each table's data. Storage positions would cause a
problem for every version X -
One problem with removing justify_hours() is that this is going to
return '24:00:00', rather than '1 day:
test= select '2004-01-02 00:00:00'::timestamptz - '2004-01-01
00:00:00'::timestamptz;
?column?
--
24:00:00
(1 row)
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
SQL commands make FTS syntax clear and follow tradition to manage
system objects. From the user's side, I'd be very unhappy to configure
FTS, which can be very complex,
RPK wrote:
Andrew,
Demanding unlimited undo at some time that is arbitrarilly distant in the
future strikes me as wholly unreasonable.
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
Bruce Momjian [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
I looked at the diff file and the major change in gram.y is the creation
of a new object type FULLTEXT,
60 matches
Mail list logo
