Could someone please clarify the difference between RETURNS NULL ON
NULL INPUT or STRICT when creating a function. Do both options exist
because of historical reasons/SQL standard compliance?
Shouldn't we raise an error when calling a function with NULL arguments
values if the function is
Thank you for making this available :)
Bruce Momjian wrote:
Gevik Babakhani wrote:
please, please, please
The video is here:
http://hosting3.epresence.tv/fosslc/1/watch/121.aspx
---
David Fetter wrote:
On
Josh Berkus wrote:
Tom, all,
* Path separator consistency on Windows
-- This discussion does not appear to have concluded. Magnus, Dave?
We've lived with this for a long time, it's nothing new. And it's not
critical. Bump to 8.5.
--
Magnus Hagander
Self: http://www.hagander.net/
Hi,
Quoting Tom Lane t...@sss.pgh.pa.us:
I can't escape the feeling that we're missing something basic here.
Perhaps the power (and importance) of merging is still a bit
underestimated, but otherwise I don't think there's much to miss.
But rebuilding the Linux kernel is hardly a
On Wed, Jun 3, 2009 at 9:45 AM, Gevik Babakhani pg...@xs4all.nl wrote:
Could someone please clarify the difference between RETURNS NULL ON NULL
INPUT or STRICT when creating a function.
They're synonyms.
Do both options exist because
of historical reasons/SQL standard compliance?
One or the
Hi,
On Wed, Jun 3, 2009 at 3:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
That's a good point; don't we recover files under names like
RECOVERYXLOG, not under names that could possibly conflict with regular
WAL
* Jeremy Kerr:
+#if defined(__GNUC__) \
+ (defined(__ppc__) || defined(__powerpc__) || \
+ defined(__ppc64__) || defined (__powerpc64__))
If you require GCC anyway, you can use __builtin_clz instead.
(It's been available since GCC 4.1 at least.)
--
Florian Weimer
I have encountered strange errors while testing PostgreSQL 8.4 beta2.
ERROR: tuple offset out of range: 0
(occasionally ERROR: tuple offset out of range: 459)
This is evidently coming from tbm_add_tuples, indicating that it's being
passed bogus TID values from the GIN index. We'll
On Wed, Jun 3, 2009 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Does that make sense?
Maybe, but it still seems messy, brute force, and error-prone.
I can't escape the feeling that we're missing something basic here.
It's allegedly one of
Hi,
Quoting David E. Wheeler da...@kineticode.com:
Monotone?
..one of the sources of inspiration for Linus to write git. He was not
satisfied with its speed and he didn't like C++ and SQL. Plus the main
contributors weren't around at the time Linus was on the mailing list.
So he turned
Shouldn't we raise an error when calling a function with NULL arguments
values if the function is created as STRICT?
No, what they do is return NULL automatically. The function doesn't
have to check for NULL arguments itself.
The RETURNS NULL ON NULL INPUT is logical and does the above
On Wed, Jun 3, 2009 at 11:04 AM, Gevik Babakhani pg...@xs4all.nl wrote:
The RETURNS NULL ON NULL INPUT is logical and does the above accordingly.
But when a function is STRICT you kind of expect to have an notification,
perhaps an error if a value for an argument is NULL.
Uhm, you might but
Greg Stark wrote:
On Wed, Jun 3, 2009 at 11:04 AM, Gevik Babakhani pg...@xs4all.nl wrote:
The RETURNS NULL ON NULL INPUT is logical and does the above accordingly.
But when a function is STRICT you kind of expect to have an notification,
perhaps an error if a value for an argument is NULL.
Hi,
Quoting Marko Kreen mark...@gmail.com:
The example was not actual case from Postgres CVS history,
but hypotetical situation without checking if it already works
with GIT.
Of course it is a simplified example, but it resembles what could
happen i.e. to the file
Florian,
+#if defined(__GNUC__) \
+ (defined(__ppc__) || defined(__powerpc__) || \
+defined(__ppc64__) || defined (__powerpc64__))
If you require GCC anyway, you can use __builtin_clz instead.
(It's been available since GCC 4.1 at least.)
Because now we have to test the compiler
* Jeremy Kerr:
Florian,
+#if defined(__GNUC__) \
+ (defined(__ppc__) || defined(__powerpc__) || \
+ defined(__ppc64__) || defined (__powerpc64__))
If you require GCC anyway, you can use __builtin_clz instead.
(It's been available since GCC 4.1 at least.)
Because now we have to
* Tom Lane:
I wondered for a second about symlinking .git from several checkout
directories to a common master, but AFAICT .git stores both the
repository and status information about the current checkout, so
that's not gonna work.
git clone --reference stores just a reference and does not
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner mar...@bluegap.ch wrote:
If you create separate commits during the conversion, rename that file on
the master branch
This is all completely irrelevant to the CVS import. I don't think
we've ever renamed files because CVS can't handle it cleanly.
Hi,
On 06/03/2009 02:08 PM, Greg Stark wrote:
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wannermar...@bluegap.ch wrote:
That would make the git history match Tom's same commit message
implicit CVS history that cvs2pcl was giving him. I find git-log's
output including merge commits kind of strange
On 06/03/2009 01:48 PM, Florian Weimer wrote:
I wondered for a second about symlinking .git from several checkout
directories to a common master, but AFAICT .git stores both the
repository and status information about the current checkout, so
that's not gonna work.
git clone --reference stores
I believe pg_migrator has advanced as far as it is going to for 8.4 and
I am expecting to enter beta next week. Here are the known pg_migrator
limitations:
---
Currently pg_migrator only supports upgrades from 8.3.X to
Emmanuel Cecchet m...@frogthinker.org writes:
Tom Lane wrote:
AFAIK that doesn't really have anything to do with the temp-ness of the
table; it'd be the same with a regular table. The problem is you have
an in-doubt tuple in pg_class for pg_temp_NNN.foo, and you are trying
to create another
Tom Lane wrote:
Emmanuel Cecchet m...@frogthinker.org writes:
Take PG 8.3.0 and try:
BEGIN;
CREATE TEMP TABLE foo (x int) ON COMMIT DROP;
PREPARE TRANSACTION 't1';
[BEGIN;] -- doesn't really matter if you start a new transaction or not
CREATE TEMP TABLE foo (x int); -- blocks until t1
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm all for marking bug fix
patches which were applied to multiple
Greg Stark wrote:
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm all for marking bug fix
patches which
On 6/3/09, Greg Stark st...@enterprisedb.com wrote:
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander mag...@hagander.net wrote:
Greg Stark wrote:
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think this makes a lot of sense to do.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 6/3/09, Magnus Hagander mag...@hagander.net wrote:
Robert Haas wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander mag...@hagander.net
wrote:
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
Robert Haas wrote:
I noticed in Bruce's talk that there are a number of post-migration
steps which are currently partially manual. Ideally we'd like to
automate them all, preferably in some sort of well-thought-out order.
I actually suspect this is something like: analyze each database,
Greg Stark st...@enterprisedb.com wrote:
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think this makes a lot of sense to do.
+1
It at least gives one a reasonable chance to get a useful clue
-Kevin
Robert Haas wrote:
The problem with making each release a separate directory is that,
just like using separate repositories, it will defeat one of the main
strengths of git, which is the ability to move around commits easily.
git-new-workdir is the only solution to the problem of having
* Magnus Hagander mag...@hagander.net [090603 10:13]:
Right, if it adds additional metadata that lets the tools do their magic
better, and it's still easy to filter out, I don't see a downside.
Note, that it could (and likely will) have a downside when you get to
doing real merge-based
* Marko Kreen mark...@gmail.com [090603 10:26]:
Thats true, but it's not representable in VCS, unless you use cherry-pick,
which is just UI around patch transport. But considering separate
local trees (with can optionally contain local per-fix branches),
it is possible to separate the
Robert Haas wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander mag...@hagander.net wrote:
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
something but I don't see any reason one is better than the
On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen mark...@gmail.com wrote:
Various scenarios with git cherry-pick and similar tools would still
result in duplicate commits, so we would need a git log post-processor
anyway if we want to somehow group them together for eg. weekly commit
summary. And
Robert Haas escribió:
On Tue, Jun 2, 2009 at 7:54 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think these are the two usable options. They will probably end up
...wait a minute. I just went and Googled this git-new-workdir thing
and it looks like it's almost exactly what we
Tom Lane wrote:
Michael Meskes mes...@postgresql.org writes:
On Mon, May 25, 2009 at 10:19:40AM -0400, Tom Lane wrote:
That sounds both dangerous and against our coding conventions. The
standard way to do that is do { ... } while (0)
Which won't work here as the macros have continue
On 6/3/09, Aidan Van Dyk ai...@highrise.ca wrote:
* Marko Kreen mark...@gmail.com [090603 10:26]:
Thats true, but it's not representable in VCS, unless you use cherry-pick,
which is just UI around patch transport. But considering separate
local trees (with can optionally contain local
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on Windows which doesn't bother me
personally but may
* Marko Kreen mark...@gmail.com [090603 11:12]:
Well, thats good to know, but this also seems to mean it's rather bad
tool for back-patching, as you risk including random unwanted commits
too that happened in the HEAD meantime. But also, it's very good
tool for forward-patching.
It doesn't
On 6/3/09, Aidan Van Dyk ai...@highrise.ca wrote:
* Marko Kreen mark...@gmail.com [090603 11:12]:
Well, thats good to know, but this also seems to mean it's rather bad
tool for back-patching, as you risk including random unwanted commits
too that happened in the HEAD meantime. But also,
Hi,
will there be a possibility to retrieve the standby situation in case of
synchronous replication ?
We would need a command or similar to report the current state and state
changes
(like: syncing, in-sync, replication broken, ..).
Observing and scaning the logfile would not be appropriate.
Gevik Babakhani pg...@xs4all.nl writes:
Perhaps it is an idea to have something like:
RAISE ERROR ON NULL INPUT
[ shrug... ] There's really been no demand for that. If you want a
particular function to do it, you can put suitable tests and error
reports into that function. I can't see us
Hi,
While analyzing some complex query and switching away from using the
materialized views to their underlying ones I got interested in the long
plan times (minutes and up) and did some profiling work.
The queries are high dimensional star-schema-alike queries
(unfortunately quite private
Hello,
First some background:
For my application I need to collect and retrieve data at a very fast rate,
faster than postgres can produce, but I also have the need to store and
access a large range of metadata about the large sets of data I am storing.
I am therefore attempting to use postgres
* Marko Kreen mark...@gmail.com [090603 11:28]:
I'm not certain, but I remember using cherry pick and seeing
several commits in result. This seems to be a point that needs
to be checked.
I'm not sure what you're recalling, but git cherry-pick takes a single
commit, and applies it as a
Florian Weimer fwei...@bfk.de writes:
* Jeremy Kerr:
Because now we have to test the compiler *and* the version as well?
This builtin is not architecture-specific, so you'd save the
architecture check.
The appropriate way to handle it would be a configure probe to see if
the function is
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on Windows which
On Wed, 2009-06-03 at 12:01 -0400, Tom Lane wrote:
I think the appropriate question is why doesn't it work on Windows,
and is that fixable? Without having looked, I'm guessing the issue
is that it depends on hardlinks or symlinks --- and we know those are
available, as long as you're using
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on Windows which doesn't bother
On Wed, Jun 3, 2009 at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the
On Wed, Jun 3, 2009 at 5:14 PM, Dave Page dp...@pgadmin.org wrote:
It's a simple perl script that uses symlinks:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/workdir/git-new-workdir
Err, shell script even.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via
Andres Freund and...@anarazel.de writes:
When switching bitmapword and companions in bitmap.h to u64 and s64
respectively I get an improvement up to 15% in queries with 16+ joins.
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at
On 06/03/2009 06:17 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I think the appropriate question is why doesn't it work on Windows,
and is that fixable? Without having looked, I'm guessing the issue
is that it depends on hardlinks or symlinks --- and we know those are
available, as long as you're
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It
Hi,
On 06/03/2009 06:21 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
When switching bitmapword and companions in bitmap.h to u64 and s64
respectively I get an improvement up to 15% in queries with 16+ joins.
I find this *really* hard to believe, because I've never seen the
Andres Freund wrote:
On 06/03/2009 06:17 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I think the appropriate question is why doesn't it work on Windows,
and is that fixable? Without having looked, I'm guessing the issue
is that it depends on hardlinks or symlinks --- and we know those are
Tom Lane wrote:
Gevik Babakhani pg...@xs4all.nl writes:
Perhaps it is an idea to have something like:
RAISE ERROR ON NULL INPUT
[ shrug... ] There's really been no demand for that. If you want a
particular function to do it, you can put suitable tests and error
reports into that function.
Andres Freund and...@anarazel.de writes:
On 06/03/2009 06:21 PM, Tom Lane wrote:
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles. What sort of
queries are you testing?
Many left joins from one base relation to
On 06/03/2009 06:38 PM, Andrew Dunstan wrote:
Andres Freund wrote:
On 06/03/2009 06:17 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I think the appropriate question is why doesn't it work on
Windows, and is that fixable? Without having looked, I'm
guessing the issue is that it depends on
Andrew Dunstan and...@dunslane.net writes:
You have carefully left out the first sentence of my reply. Neither of
the committers who actually do much work on Windows (namely Magnus and
me) commit direct from *any* version of Windows.
Nonetheless, that might not be true in future. I'd be a
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
On 06/03/2009 06:21 PM, Tom Lane wrote:
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles. What sort of
queries are you testing?
Bruce Momjian wrote:
pg_migrator will require a reindex if:
o an index is of type hash or gin
o an index uses bpchar_pattern_ops
What about varchar_pattern_ops and text_pattern_ops? Are they not
affected?
--
Alvaro Herrera
Andres Freund and...@anarazel.de wrote:
long plan times (minutes and up)
Wow. I thought I had some pretty complex queries, including some
which join using several views, each of which has several joins; but
I've never gone to multiple seconds on plan time (much less multiple
minutes!)
Tatsuo Ishii is...@postgresql.org writes:
Sorry for delay. I have put a database dump at:
http://sylpheed.sraoss.jp/tmp/dump.sql.gz
We got following errors using this database:
Hmm. I can confirm the unrecognized operator failure (though I get
8 not -50 ... uninitialized memory?). The tuple
Markus Wanner wrote:
Hi,
Quoting David E. Wheeler da...@kineticode.com:
Monotone?
..one of the sources of inspiration for Linus to write git. He was not
satisfied with its speed and he didn't like C++ and SQL. Plus the main
contributors weren't around at the time Linus was on the
Andrew Dunstan wrote:
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on
Andres Freund wrote:
The git for windows installation includes a functional unix-alike shell
(mingw, not cygwin or such). Some core part of git are still written in
shell, so it would not work without that anyway.
Ah. Ok. Good to know. Does it contain a builtin ln command? And does
that
Alvaro Herrera alvhe...@commandprompt.com writes:
Bruce Momjian wrote:
pg_migrator will require a reindex if:
o an index is of type hash or gin
o an index uses bpchar_pattern_ops
What about varchar_pattern_ops and text_pattern_ops? Are they not
affected?
Nope. See
Hi,
On 06/03/2009 07:26 PM, Andrew Dunstan wrote:
Andres Freund wrote:
The git for windows installation includes a functional unix-alike shell
(mingw, not cygwin or such). Some core part of git are still written in
shell, so it would not work without that anyway.
Ah. Ok. Good to know. Does it
Magnus Hagander wrote:
Andrew Dunstan wrote:
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
Josh Berkus j...@agliodbs.com writes:
More suggested dispositions:
* contrib/seg and contrib/cube GiST index support have performance issues
-- If it's just a performance issue, I don't think this issue should
block 8.4.0; it can be fixed in 8.4.1 if necessary, since we'll probably
Magnus Hagander mag...@hagander.net writes:
Josh Berkus wrote:
* Path separator consistency on Windows
-- This discussion does not appear to have concluded. Magnus, Dave?
We've lived with this for a long time, it's nothing new. And it's not
critical. Bump to 8.5.
This is partly my fault,
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Josh Berkus wrote:
* Path separator consistency on Windows
-- This discussion does not appear to have concluded. Magnus, Dave?
We've lived with this for a long time, it's nothing new. And it's not
critical. Bump to 8.5.
This
Hiroshi Inoue in...@tpf.co.jp writes:
Tom Lane wrote:
* This seems to be assuming that the user has set LC_MONETARY and
LC_NUMERIC the same. What if they're different?
Strictky speaking they should be handled individually.
I thought about this some more, and I wonder why you did it like
Tatsuo Ishii is...@postgresql.org writes:
STATEMENT: SELECT msg_sid, hdr_from, hdr_to, hdr_subject, msg_date,
folder_id, msgnum FROM msginfo LEFT JOIN msg_folderinfo USING (msg_sid) WHERE
plainto_tsquery(E'a') @@ body_index
NOTICE: text-search query contains only stop words or doesn't
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andres Freund and...@anarazel.de wrote:
long plan times (minutes and up)
Wow. I thought I had some pretty complex queries, including some
which join using several views, each of which has several joins; but
I've never gone to
Gregory Stark st...@enterprisedb.com writes:
But that doesn't explain the bitmap ops being important. Hm. Actually
having a lot of columns and then joining a lot of tables could mean
having fairly large bitmapsets.
Yeah, but then you have a lot of *other* expensive operations too,
such as the
Robert Haas wrote:
But I
wonder if it would make more sense to include some kind of metadata in
the commit message (or some other property of the commit? does git
support that?) to make it not depend on that.
From elsewhere in this thread[1], 'The git cherry-pick ... -x flag adds
a note to
Gregory Stark st...@enterprisedb.com wrote:
My money's still on very large statistics targets. If you have a lot
of columns and 1,000-element arrays for each column that can get big
pretty quickly.
I'm finding that even the ones that had a plan time in the range of
260 ms go down to 15 ms
My last post on the git issue... If any one wants to ask specific
questions, feel free to e-mail me directly... But this thread has
digressed to way too much hand-waving...
If any of your are not familiar with git and want to get an overview of
it, this might be a good place to start:
Zdenek Kotala píše v po 01. 06. 2009 v 22:45 +0200:
Tom Lane píše v po 01. 06. 2009 v 16:09 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
What is sys/list.h, and why is it being imported by the Perl headers?
It seems that problem is with Perl. It includes sys/mode.h. The new
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Gregory Stark st...@enterprisedb.com wrote:
My money's still on very large statistics targets. If you have a lot
of columns and 1,000-element arrays for each column that can get big
pretty quickly.
I'm finding
Robert Haas robertmh...@gmail.com wrote:
When you say, don't fit in cache, exactly what
cache are you talking about? It seems to me that the statistics
should be far smaller than the underlying tables, so if even your
statistics don't fit in shared buffers (let alone main memory), it
Tom Lane wrote:
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
issue because the transaction is done executing, but the tqual.c
rules
After looking through the current uses of ngettext(), I think that it
wouldn't be too difficult to modify the patch to address the concerns
I had about it. What I propose doing is to add an additional elog.h
function
errmsg_plural(const char *fmt_singular, const char *fmt_plural,
Emmanuel Cecchet m...@frogthinker.org writes:
Tom Lane wrote:
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
issue because the
Emmanuel Cecchet wrote:
Tom Lane wrote:
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
issue because the transaction is done
Hello
can you send source code? There are two types of C SRF functions. One
returns row ro by row, second store returned rows and returns block.
What did you use?
ignore comments (in czech please) and look on code -
http://www.postgres.cz/index.php/Iter%C3%A1tor_pole
regards
Pavel Stehule
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Since he can't share the schema, and hasn't even given much of a hint,
I don't know whether one (or more) of the columns is a bytea filled
with 100 MB values; and I don't remember any description of the
hardware environment either. Since the
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I'm finding that even the ones that had a plan time in the range of
260 ms go down to 15 ms to 85 ms once the statistics are cached.
I had some performance results back
Tom Lane wrote:
Emmanuel Cecchet m...@frogthinker.org writes:
Tom Lane wrote:
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
Emmanuel Cecchet m...@frogthinker.org writes:
But when the transaction prepares, we know that. What would prevent us
to do at prepare time the same cleanup that commit does?
The entire point of PREPARE is that it's *not* committed yet.
regards, tom lane
--
Sent via
Hmm. I can confirm the unrecognized operator failure (though I get
8 not -50 ... uninitialized memory?). The tuple out of range
failures are not happening here though. Perhaps it is locale dependent?
What locale are you using, and what is your default_text_search_config
setting? Are you
On 06/03/2009 07:05 PM, Kevin Grittner wrote:
Andres Freundand...@anarazel.de wrote:
long plan times (minutes and up)
Wow. I thought I had some pretty complex queries, including some
which join using several views, each of which has several joins; but
I've never gone to multiple seconds on
Doesn't that still add up to 3GB for a table's stats in the worst
case? 1kb * 1,000 buckets * 1,500 attributes * 2 (histogram + mfv)
Except you can't actually get 1500 toast pointers on a page. I suppose
with games with nulls you could make this worst case happen though.
It does seem like
Greg Stark greg.st...@enterprisedb.com writes:
It does seem like it ought to be possible to truncate strings in the
histogram since any string between the actual values us equally good.
Yeah, that was the justification for dropping the wide values ---
that and the theory that they'd be
Tatsuo Ishii is...@postgresql.org writes:
initdb -E UTF-8 --no-locale /path/to/database
So locale is C. I believe we are not customizing
default_text_search_config. I'm not think of any nondefault
configuration settings.
Huh. So that should be the same case I tested here. I wonder why
I
On Wed, 3 Jun 2009, Tom Lane wrote:
Tatsuo Ishii is...@postgresql.org writes:
initdb -E UTF-8 --no-locale /path/to/database
So locale is C. I believe we are not customizing
default_text_search_config. I'm not think of any nondefault
configuration settings.
Huh. So that should be the same
1 - 100 of 117 matches
Mail list logo
