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 FUL
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 databa
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,
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)
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
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
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" functional
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
---
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 t
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 app
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 wrot
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
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 configur
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, Andr
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 on
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 rat
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 m
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
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.
---
Te
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 m
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
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 fo
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 research.
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_t
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
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
o
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
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 the
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
i
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; perfor
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
"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
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 tim
Ü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 disc
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.
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 pract
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 Oracl
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
> buffe
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 for
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 sha
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
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 poss
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 upgrad
> 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 vyj
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
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 followe
"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 care
> 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 appe
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.
> >
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 al
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
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
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
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
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 GENERATED
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
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/
---(en
"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
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 row
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
60 matches
Mail list logo
