On Thu, Feb 25, 2010 at 4:31 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I have one question. Do we support starting an archive recovery and
standby server from a cold backup (not a base backup taken by online
backup)? Though I think they would work and be very useful, I'm
Fujii Masao wrote:
On Thu, Feb 25, 2010 at 9:31 AM, Erik Rijkers e...@xs4all.nl wrote:
On Wed, February 24, 2010 20:40, Erik Rijkers wrote:
pg_last_xlog_receive_location | pg_xlogfile_name_offset
---+---
E2/C012AD90
Hello,
I was reading the SR docs, and have the following question:
Is there a fundamental reason why archive_command etc. is required in
streaming replication mode?
Can`t setting up the standby be more like:
pg_start_streaming_backup() on the master (this will be queuing up
files in pg_xlog)
copy
marcin mank wrote:
I was reading the SR docs, and have the following question:
Is there a fundamental reason why archive_command etc. is required in
streaming replication mode?
Can`t setting up the standby be more like:
pg_start_streaming_backup() on the master (this will be queuing up
On Thu, Feb 25, 2010 at 5:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
A quick fix would be to just throw an error if you try to use
pg_xlog_filename() during hot standby. But there seems to be good
reasons to call pg_xlog_filename() during hot standby, given that both
I just noticed that the revision numbering for the new
src/doc/sgml/recovery-config.sgml file I added started from 2 for some
reason. The first revision was 2.1, and when I just updated it the new
revision became 2.2.
It seems to work fine, but I've never seen CVS revision numbers like
that
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@sss.pgh.pa.us:
Also, the coding seems a bit confused about whether the
ssl_renegotiation_limit GUC exists when USE_SSL isn't set. I think we
have a project
On Thu, Feb 25, 2010 at 10:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
the standby needs to
fall back to the archive if it falls behind so that the WAL files it
needs have already been recycled in the master.
Oh, so the master does not have to keep track of the state
Fujii Masao wrote:
On Thu, Feb 25, 2010 at 5:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
A quick fix would be to just throw an error if you try to use
pg_xlog_filename() during hot standby. But there seems to be good
reasons to call pg_xlog_filename() during hot
Rémi Zara írta:
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit :
Here's the attached test code. Compile it with
gcc -Wall -o nantest nantest.c -lm
and run it. It tests NAN anf INFINITY values with isinf() and isnan().
The expected output is:
==
$ ./nantest
Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit :
NAN on NetBSD/x86-64 is defined as:
extern const union __float_u __nanf;
#define NAN __nanf.__val
Same here:
math.h:extern const union __float_u __nanf;
math.h:#define NAN __nanf.__val
I would guess that it's
On Thu, Feb 25, 2010 at 7:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah. The current pg_*_last_location() functions don't cut it though,
you need to retain logs back to the redo location of the last
restartpoint. That's what %r returns. Maybe we should add another
Yes. When a bit is cleared, that's OK, because a cleared bit just means
you need to check visibility in the heap tuple. When a bit is set,
however, it's important that it doesn't hit the disk before the
corresponding heap page update. That's why visibilitymap_set() sets the
LSN on the page.
The replay of the heap insert/update/delete record updates the
visibility map.
So are you planning to make that section, which writes the xlog and updates
the visibility map inside a PANIC section right?
On Thu, 2010-02-25 at 12:02 +0900, Fujii Masao wrote:
On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote:
Fujii Masao wrote:
In relation to the functions added recently, I found an annoying problem;
The replay of the heap insert/update/delete record updates the
visibility map.
Say a checkpoint has occured in between and flushed the dirty pages into
disk, while the updater waits to update the visibility map. Now there will
be no replay for the insert/update/delete right?
I wrote:
As Rémi says, isnan((double)(0.0 / 0.0)) == true for him.
Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division
produces NaN. How about doing it explicitely in ECPG?
I came up with three patches, they are attached.
Can you try whether the first patch (missing float.h
Gokulakannan Somasundaram wrote:
OK. Say a session doing the update, which is the fist update on the page,
resets the PD_ALL_VISIBLE and just before updating the visibility map
crashes. The subsequent inserts/updates/deletes, will see the PD_ALL_VISIBLE
flag cleared and never care to update
Gokulakannan Somasundaram wrote:
The replay of the heap insert/update/delete record updates the
visibility map.
So are you planning to make that section, which writes the xlog and updates
the visibility map inside a PANIC section right?
The xlog record is already written in a critical
Gokulakannan Somasundaram wrote:
Say a checkpoint has occured in between and flushed the dirty pages into
disk, while the updater waits to update the visibility map. Now there will
be no replay for the insert/update/delete right?
Yeah, good catch, that could happen.
--
Heikki Linnakangas
On Thu, Feb 25, 2010 at 10:42, Magnus Hagander mag...@hagander.net wrote:
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Fair enough, USERSET it is then.
Done. Will run some tests and then apply.
And applied.
I backpatched it to
On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Committed removal of that and the assertion. You still can't use a copy
of the data directory taken right after initdb, because the initial
checkpoint record has the flag set indicating that archiving
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit :
Is this buildfarm member for detecting bugs in the already
obsolete NetBSD 5.0 BETA, or what? The final 5.0 and
two bugfix releases are already out for a while. The owner
of that particular machine should upgrade.
I upgraded pika
Hi all,
I got following stack:
fd7ffed14b70 strlen () + 40
fd7ffed71665 snprintf () + e5
fd7fff36d088 pg_GSS_startup () + 88
fd7fff36d43a pg_fe_sendauth () + 15a
fd7fff36e557 PQconnectPoll () + 3b7
fd7fff36e152 connectDBComplete () + a2
fd7fff36dc32
On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote:
Hi all,
I got following stack:
fd7ffed14b70 strlen () + 40
fd7ffed71665 snprintf () + e5
fd7fff36d088 pg_GSS_startup () + 88
fd7fff36d43a pg_fe_sendauth () + 15a
fd7fff36e557 PQconnectPoll
Magnus Hagander mag...@hagander.net writes:
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
I see that ssl_ciphers is made to go away when USE_SSL isn't set,
so the most consistent thing in the near term would be to do the same.
The difference is that ssl_ciphers is only set
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I just noticed that the revision numbering for the new
src/doc/sgml/recovery-config.sgml file I added started from 2 for some
reason. The first revision was 2.1, and when I just updated it the new
revision became 2.2.
It seems to
On Thu, Feb 25, 2010 at 15:27, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
I see that ssl_ciphers is made to go away when USE_SSL isn't set,
so the most consistent thing in the near term would
On Wed, Feb 24, 2010 at 11:14 PM, Josh Berkus j...@agliodbs.com wrote:
Right. I'm pointing out that production and trying out 9.0 for the
first time are actually different circumstances, and we need to be able
to handle both gracefully. Since, if people have a bad experience
trying it out
Magnus Hagander mag...@hagander.net writes:
I backpatched it to 8.2, which is as far as it applied fairly cleanly.
Before that, we don't have GUC_UNIT_KB for example, so it'll be a
different format of the patch as well. I'm not sure it's important
enough to go back beyond that...
Hm, I'd
Heikki Linnakangas wrote:
I just noticed that the revision numbering for the new
src/doc/sgml/recovery-config.sgml file I added started from 2 for some
reason. The first revision was 2.1, and when I just updated it the new
revision became 2.2.
It seems to work fine, but I've never seen CVS
Boszormenyi Zoltan z...@cybertec.at writes:
Can you try whether the first patch (missing float.h from data.c)
solves the problem? And together with the 2nd one? In that
patch I fixed the order of float.h and math.h in nan_test.pgc,
which is the opposite of the order found in e.g.
On Thu, Feb 25, 2010 at 6:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
If we expose the timeline as part of an xlog location, then we should
do that everywhere as a change for 9.0.
Everywhere? You mean changing the format of the return value of all
the following functions?
-
Andrew Dunstan wrote:
For some unknown reason, we have some version 2.x files in
doc/src/sgml:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/,
which is why
you saw this.
Most likely, somebody incremented the rev number by hand in the dawn of
time. Your doc also says:
On Thu, Feb 25, 2010 at 11:57 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So it's not the TLI of the first record in the file, isn't it?
Hmm, or is it the TLI of the last record? Not sure. Anyway,
Heikki Linnakangas wrote:
Josh Berkus wrote:
OK, can you go through the reasons why pg_stop_backup would not
complete?
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
Yes,
From memory and the thread below, I thought one of the key uses was to
let me use a module from trusted plperl.
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00167.php
The example below has a TestModule that just exports one sub - visible
from plerlu but not plperl. Presumably Safe
Richard Huxton wrote:
From memory and the thread below, I thought one of the key uses was to
let me use a module from trusted plperl.
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00167.php
The example below has a TestModule that just exports one sub - visible
from plerlu but
On 25/02/10 17:10, Andrew Dunstan wrote:
Richard Huxton wrote:
Presumably Safe just clamps down and my
sub isn't marked as acceptable. Is this intended, or am I doing
something stupid?
It's intended (at least by me).
Also, please see the recent discussion about loading extra stuff into
the
Greg Stark wrote:
In an ideal world it would be best if pg_stop_backup could actually
print the error status of the archiving command. Is there any way for
it to get ahold of the fact that the archiving is failing?
This is in the area I mentioned I'd proposed a patch to improve not too
On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan and...@dunslane.net wrote:
Bruce Momjian wrote:
I have a TODO on fixing some of the typedef finding. But I can generate
an up to date version of the list Bruce last used in a day or two, and then
get this better whacked into shape for another
On Tue, Feb 23, 2010 at 11:08 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Steve Atkins wrote:
Would having a higher level process manager be adequate - one
that spawns the postmaster and a list of associated processes
(queue manager, job scheduler, random user daemons that are
used
Dominik Sander depai...@gmail.com writes:
I have an issue with a table partitioned by one boolean column. The
query planner only seems to skip the non matching table if expired
(the column I use for the partition) is true.
Hm, interesting case. The reason it's behaving asymmetrically is the
1) transaction information in index
This seems like a lot of bloat in indexes. It also means breaking
a lot of other optimizations such as being able to read the tuples
directly from the heap page without locking. I'm not sure how much
those are worth though. But adding 24 bytes to every
Joshua D. Drake wrote:
On Wed, 2010-02-24 at 12:32 -0800, Josh Berkus wrote:
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
OK, so we need a way out of that cycle if the
Robert Haas wrote:
On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan and...@dunslane.net wrote:
Bruce Momjian wrote:
I have a TODO on fixing some of the typedef finding. But I can generate
an up to date version of the list Bruce last used in a day or two, and
then
get this better
If you're adventurous enough, it's actually possible to set an
archive_command that checks the status of the standby and returns
failure as long as the standby still needs the given WAL segment. That
way the primary doesn't recycle segments that are still needed by the
standby, and you can
On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan and...@dunslane.net wrote:
Bruce Momjian wrote:
I have a TODO on fixing some of the typedef finding. But I can generate
an up to date version of the
Gokulakannan Somasundaram gokul...@gmail.com writes:
I think, somewhere things have been misunderstood. we only need 8
bytes more per index entry. I thought Postgres has a 8 byte transaction id,
but it is only 4 bytes, so we only need to save the insertion and deletion
xids. So 8
On Thu, Feb 25, 2010 at 8:09 PM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
I think, somewhere things have been misunderstood. we only need 8
bytes more per index entry. I thought Postgres has a 8 byte transaction id,
but it is only 4 bytes, so we only need to save the
Looks like we arrived at the best solution here. I don't think it was
clear to users that pg_stop_backup() was issuing an archive_command and
hence they wouldn't be likely to understand the delay or correct a
problem. This gives them the information they need at the time they
need it.
Greg Stark gsst...@mit.edu writes:
In indexes we currently get away with a reduced header which has few
of the 6 bytes of info bits. However the only reason we can do is
because we impose arbitrary limitations that work for indexes but
wouldn't be reasonable for tables. Such as a lower maximum
On Thu, February 25, 2010 17:34, Fujii Masao wrote:
I attached the revised patch which uses lastPageTLI instead of curFileTLI
as the timeline of the last applied record.
With this patch the standby compiles, tests, installs OK.
I wanted to check with you if the following is expected.
With
Robert Haas wrote:
On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan and...@dunslane.net
wrote:
Bruce Momjian wrote:
I have a TODO on fixing some of the typedef finding. But I can generate
an
hello to everyone,
is a bit late for an italian, but after an long day debugging I had an idea.
Why not introduce a special SQL command like
STORE WHERE [condition] FROM [table]
removing all data that meet the condition and storing them into another
database?
Then, if a query that needs the
Wait a second, which idea are we currently talking about? No heap at
all, or just the ability to check visibility without visiting the heap?
I was talking about the indexes with snapshot
If it's a genuine IOT (ie no separate heap), then you are not going to
be able to get away without a
...could be
STORE WHERE [condition] FROM [table] INTO [database]
regards
Omar Bettin
- Original Message -
From: Robert Haas robertmh...@gmail.com
To: Omar Bettin o.bet...@informaticaindustriale.it
Cc: pgsql-hackers@postgresql.org
Sent: Thursday, February 25, 2010 11:11 PM
Subject: Re:
On Thu, Feb 25, 2010 at 5:17 PM, Omar Bettin
o.bet...@informaticaindustriale.it wrote:
...could be
STORE WHERE [condition] FROM [table] INTO [database]
That still doesn't work, because a PostgreSQL backend doesn't have any
obvious way to access another database. You'd need to use dblink or
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Does that mean you're going to do it, or are you waiting for some sort
of OK? I believe everyone who expressed an opinion is in favor.
I was waiting a few hours to get feedback. I will do it at 0100 GMT
(2000 EST).
You can do it
On Thu, Feb 25, 2010 at 4:35 PM, Omar Bettin
o.bet...@informaticaindustriale.it wrote:
hello to everyone,
is a bit late for an italian, but after an long day debugging I had an idea.
Why not introduce a special SQL command like
STORE WHERE [condition] FROM [table]
removing all data that meet
decibel wrote:
One of the talks at PGCon (update in place?) recommended running
vacuumdb -z to analyze all tables to rebuild statistics. Problem with
that is it also vacuums everything. ISTM it'd be useful to be able to
just vacuum all databases in a cluster, so I hacked it into
On Thu, Feb 25, 2010 at 4:48 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan and...@dunslane.net
wrote:
Bruce Momjian wrote:
I have
I have read that 8.5 will have replication, so is just a feature request.
regards
Omar Bettin
- Original Message -
From: Robert Haas robertmh...@gmail.com
To: Omar Bettin o.bet...@informaticaindustriale.it
Cc: pgsql-hackers@postgresql.org
Sent: Thursday, February 25, 2010 11:22 PM
David, I am sorry this didn't get applied, and the code has drifted too
much to apply it now. Would you be able to make a new patch to make our
Perl files strict?
---
David Fetter wrote:
On Fri, May 08, 2009 at 09:04:18PM
On Thu, Feb 25, 2010 at 05:39:10PM -0500, Bruce Momjian wrote:
David, I am sorry this didn't get applied, and the code has drifted too
much to apply it now. Would you be able to make a new patch to make our
Perl files strict?
Please find updated patch attached. It passes strict, warnings,
The other
problem is the extra write load created by needing to update the index's
copies of the hint bits; not to mention extra writes to freeze the xids
when they get old enough.
But Tom, i remember that the vacuum was faster when index had visibility
info, since we need not touch the
On Thu, Feb 25, 2010 at 9:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We've sweated
blood to get that struct down to where it is; there's no way to make it
smaller without giving up some really fundamental things, for example
the ability to do UPDATE :-(
Oh, this is a tangent but I think there
Greg Stark gsst...@mit.edu writes:
2) Now that we don't have vacuum full the command-id is kind of a
waste.
Not really.
We could replace it with some kind of local memory data
structure which is capable of spilling to disk.
The performance costs of that would probably outweigh any space
If it's of any interest, I can say something about the hint bits in the
index tuple header. In my implementation, my decision was to use only one
hint bit. It went into the unused 13th bit of the IndexTuple header. When
the hint bit is set, it means that
(xmin is committed OR xmin =
I disagree with that, Gokul -- if the ordering operators are volatile or
just incorrect, during DELETE, you could set xmax in the wrong IndexTuple.
Then there will be another IndexTuple that says it's visible, but it points
to a non-visible heap tuple. I think you should follow the pointers
David Fetter da...@fetter.org writes:
-} elsif ($minor eq devel) {
-$dotneeded = 0;
-$numericminor = 0;
-} elsif ($minor =~ m/^alpha\d+$/) {
-$dotneeded = 0;
-$numericminor = 0;
-} elsif ($minor =~ m/^beta\d+$/) {
-$dotneeded = 0;
-$numericminor = 0;
-} elsif
On Thu, Feb 25, 2010 at 3:59 PM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
I disagree with that, Gokul -- if the ordering operators are volatile or
just incorrect, during DELETE, you could set xmax in the wrong IndexTuple.
Then there will be another IndexTuple that says it's
Karl Schnaitter karl...@gmail.com writes:
If it's of any interest, I can say something about the hint bits in the
index tuple header. In my implementation, my decision was to use only one
hint bit. It went into the unused 13th bit of the IndexTuple header. When
the hint bit is set, it means
Did we ever get tab completion support for these backslash commands?
---
David Fetter wrote:
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Is this any better?
So what
Karl Schnaitter karl...@gmail.com writes:
Of course, PG can't support indexing with incorrect functions. However,
it's worthwhile to guard against too much damage being done if the user's
function has a bug. Maybe I'm wrong? Maybe an index tuple with a dangling
pointer is actually harmless?
Robert Haas wrote:
On Thu, Feb 25, 2010 at 4:48 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan and...@dunslane.net
wrote:
I assume we decided we didn't want this.
---
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
Here is the revised patch; If stats_temp_directory indicates the symlink,
we pursue the chain of symlinks and
Robert Haas wrote:
On Wed, Feb 17, 2010 at 5:52 PM, Jeroen Vermeulen j...@xs4all.nl wrote:
I may have cut this out of my original email for brevity... my impression is
that the planner's estimate is likely to err on the side of scalability, not
best-case response time; and that this is more
Whatever happened to this? It was in the first 9.0 commitfest but was
returned with feedback but never updated:
https://commitfest.postgresql.org/action/patch_view?id=75
---
Pavan Deolasee wrote:
ISTM that the
Bruce Momjian br...@momjian.us writes:
I assume we decided we didn't want this.
I thought the risk/reward ratio was pretty bad.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assume we decided we didn't want this.
I thought the risk/reward ratio was pretty bad.
Yea, the symlink issue killed it for me.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Thu, Feb 25, 2010 at 9:03 PM, Bruce Momjian br...@momjian.us wrote:
Done. The diff is here:
http://momjian.us/tmp/pgindent.diff
and I checked into CVS a copy of the typedef list I used from Andrew
Dunstan.
Cool, thanks. Let the rebasing (if any) begin.
...Robert
--
Sent via
On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
While we're at it, the error message doesn't seem right:
FATAL: recovery connections cannot start because the
recovery_connections parameter is disabled on the WAL source server
On Thu, Feb 25, 2010 at 9:48 PM, Jeroen Vermeulen j...@xs4all.nl wrote:
Robert Haas wrote:
On Wed, Feb 17, 2010 at 5:52 PM, Jeroen Vermeulen j...@xs4all.nl wrote:
I may have cut this out of my original email for brevity... my impression
is
that the planner's estimate is likely to err on the
On Thu, Feb 25, 2010 at 9:49 PM, Bruce Momjian br...@momjian.us wrote:
Whatever happened to this? It was in the first 9.0 commitfest but was
returned with feedback but never updated:
https://commitfest.postgresql.org/action/patch_view?id=75
Well, the patch author chose not to pursue
Robert Haas wrote:
On Thu, Feb 25, 2010 at 9:49 PM, Bruce Momjian br...@momjian.us wrote:
Whatever happened to this? ?It was in the first 9.0 commitfest but was
returned with feedback but never updated:
? ? ? ?https://commitfest.postgresql.org/action/patch_view?id=75
Well, the patch
Robert Haas robertmh...@gmail.com writes:
I actually think there isn't any clean line. Obscene is in the eye of
the beholder. Frankly, I think this discussion is getting off into
the weeds. It would be nice, perhaps, to have a feature that will
detect when the generic plan is the suxxor and
On Thu, Feb 25, 2010 at 10:32 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Feb 25, 2010 at 9:49 PM, Bruce Momjian br...@momjian.us wrote:
Whatever happened to this? ?It was in the first 9.0 commitfest but was
returned with feedback but never updated:
? ? ?
On Thu, Feb 25, 2010 at 5:09 PM, Bruce Momjian br...@momjian.us wrote:
This is implemented in 9.0 from vacuumdb:
-Z, --analyze-only only update optimizer hints
maybe just noise, but it's not better to say optimizer statistics
instead of optimizer hints?
--
On Thu, Feb 25, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I actually think there isn't any clean line. Obscene is in the eye of
the beholder. Frankly, I think this discussion is getting off into
the weeds. It would be nice, perhaps, to
Tom,
Actually, if you need to squeeze a few more bits into that word, the
thing to do would be to get rid of storing the tuple length there.
This would involve adding the same type of indirection header that
we use for HeapTuples, so that the length would be available at need
without going
Jaime Casanova wrote:
On Thu, Feb 25, 2010 at 5:09 PM, Bruce Momjian br...@momjian.us wrote:
This is implemented in 9.0 from vacuumdb:
? ? ? ? ?-Z, --analyze-only ? ? ? ? ? ? ?only update optimizer hints
maybe just noise, but it's not better to say optimizer statistics
instead of
I assume we never came to any conclusion on this.
---
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Answering myself here: the filesize for the frontend only part is
about 2k on
On Fri, Feb 26, 2010 at 8:19 AM, Bruce Momjian br...@momjian.us wrote:
Whatever happened to this? It was in the first 9.0 commitfest but was
returned with feedback but never updated:
Though Alex did some useful tests and review, and in fact confirmed that the
VACUUM time dropped from 16494
First of all, volatility is not the only issue. The ordering ops could also
be incorrect, e.g., violate the transitivity property. there is no reliable
way to determine if a function is volatile and/or incorrectly specified.
No it is the only issue. If you create a datatype with volatile
No, it's far from harmless. As soon as that heap TID gets filled with
an unrelated tuple, you run the risk of indexscans alighting on and
perhaps modifying the wrong tuple.
Tom,
In the Function based indexes on those functions, which we are
suspecting to be a volatile one Or in the
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 25, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still like the idea of automatically replanning with the known
parameter values, and noting whether the result plan was estimated to be
noticeably cheaper than the generic plan, and
On Thu, Feb 25, 2010 at 20:40, Tom Lane t...@sss.pgh.pa.us wrote:
It's not going to be easier to implement. Yeah, it would be easy to
provide a global switch via a GUC setting, but that's not going to be
helpful, because this is the sort of thing that really needs to be
managed per-query.
On Fri, Feb 26, 2010 at 9:54 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
No, it's far from harmless. As soon as that heap TID gets filled with
an unrelated tuple, you run the risk of indexscans alighting on and
perhaps modifying the wrong tuple.
Tom,
i think this will
On Thu, Feb 25, 2010 at 21:28, Alex Hunsaker bada...@gmail.com wrote:
Not to mention you can already do this more or less client side with a
nice driver.
[ uninformed noise ... ]
I did seem to miss the part where everyone thinks this is a crock...
But I don't remember seeing numbers on parse
1 - 100 of 109 matches
Mail list logo
