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
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 index
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 posit
I notice that this patch:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h.diff?r1=1.443&r2=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 si
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 i
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 i
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
On 2/19/07, Oleg Bartunov 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
of the full stri
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 array
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 ba
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
> 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 tabl
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 dev
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
Ü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'
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 ca
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 t
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
>
> > 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 some
> > >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 the
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 started
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
On Mon, 19 Feb 2007, Guillaume Smet wrote:
On 2/19/07, Oleg Bartunov 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
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 h
"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
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 s
"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 e
Martijn van Oosterhout 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 "name"
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 act
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 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
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 ch
On 2/19/07, Oleg Bartunov 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 broadcast)---
TI
"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 code
Le lundi 19 février 2007 16:33, Tom Lane a écrit :
> Martijn van Oosterhout 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.
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, muc
-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 t
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 cod
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 hardwir
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 m
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 b
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 my
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'
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 ExecCon
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:
> >>>http://developer.postgresql.org/inde
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 u
Tom Lane wrote:
> Martijn van Oosterhout 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 someone will poin
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Martijn van Oosterhout 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.
>
>
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Martijn van Oosterhout 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.
>
>
"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 no
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 "
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 b
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 donat
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 cont
Stefan Kaltenbrunner wrote:
> Peter Eisentraut wrote:
>> Tom Lane wrote:
>>> Martijn van Oosterhout 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 exi
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 exa
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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
Andrew Sullivan wrote:
> On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
>> Martijn van Oosterhout 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 alrea
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
Th
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 writes:
> >>> Somehow this seems like implementing RAID within postgres,
> >> RAID and LVM too. I can't get excited about re-inventing those wheels
> >> when p
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
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 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 implementat
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 2
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 w
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?
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
Did we come to a conclusion on this?
---
Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> >
> >
> > Tom Lane wrote:
> >> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >>
> >>> The consequence will be, though, that psql will
On Mon, 2007-02-19 at 17:35 -0300, Alvaro Herrera wrote:
> Andrew Sullivan wrote:
> > On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> > > Martijn van Oosterhout writes:
> > > > Somehow this seems like implementing RAID within postgres,
> > >
> > > RAID and LVM too. I can't get excite
Added to developer's FAQ:
src/Makefile.custom can be used to set environment variables,
like CUSTOM_COPT, that are used for every compile.
---
Magnus Hagander wrote:
> >> If we did what you suggest, then --enable-
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 cache
"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
>
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:
http://archives.postgresql.org/pgsql-patc
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
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 interrupt
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 writes:
> > > Somehow this seems like implementing RAID within postgres,
> >
> > RAID and LVM too. I can't get excited about re-inventing those
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 broadcast)---
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 cons
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
> >>
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
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 Du
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.
>
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 tail
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 li
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 situati
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 inv
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 writes:
> > >>> Somehow this seems like implementing RAID within postgres,
> > >>
> > >> RAID and
1 - 100 of 107 matches
Mail list logo
