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 Fr
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.n
Hi,
Quoting "Tom Lane" :
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 zero-cost operation,
so h
On Wed, Jun 3, 2009 at 9:45 AM, Gevik Babakhani 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 other,
Hi,
On Wed, Jun 3, 2009 at 3:54 AM, Tom Lane wrote:
> Heikki Linnakangas 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 files?
>
>> Yes. But we rename RECOVERYXLOG to
* 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.
On Wed, Jun 3, 2009 at 12:39 AM, Tom Lane wrote:
> "David E. Wheeler" 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 git's great strengths that it a
Hi,
Quoting "David E. Wheeler" :
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 away and did his ow
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
acco
On Wed, Jun 3, 2009 at 11:04 AM, Gevik Babakhani 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 I'm not sure
Greg Stark wrote:
On Wed, Jun 3, 2009 at 11:04 AM, Gevik Babakhani 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 b
Hi,
Quoting "Marko Kreen" :
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 doc/src/sgml/generate_history.pl, which go
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
* 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.)
>
> Becau
* 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 doe
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner 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.
It does sound to
Hi,
On 06/03/2009 02:08 PM, Greg Stark wrote:
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner 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 and annoying my
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" stor
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 8.4.X
Emmanuel Cecchet 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 one for the
Tom Lane wrote:
Emmanuel Cecchet 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 commits
I have been
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund 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 branches as me
Greg Stark wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund 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 ap
On 6/3/09, Greg Stark wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund 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
> pat
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander wrote:
> Greg Stark wrote:
>> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund 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 s
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:
http://www
On 6/3/09, Magnus Hagander wrote:
> Robert Haas wrote:
> > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander
> 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
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 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
--
Sent via pgsql-
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 mul
* Magnus Hagander [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 development... A "merge
* Marko Kreen [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 fix-developement fr
Robert Haas wrote:
> On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander 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 other.
>> If yo
On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen 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 such post-pro
Robert Haas escribió:
> On Tue, Jun 2, 2009 at 7:54 PM, Alvaro Herrera
> 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 need. According to
Tom Lane wrote:
> Michael Meskes 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 and break
On 6/3/09, Aidan Van Dyk wrote:
> * Marko Kreen [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
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
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 be a showstopper more
* Marko Kreen [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 "pull in comm
On 6/3/09, Aidan Van Dyk wrote:
> * Marko Kreen [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 fo
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.
Ar
Gevik Babakhani 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 adding extra
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 (hea
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 [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 single commit (or, w
Florian Weimer 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 available, thu
Dave Page writes:
> On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
> 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
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 usin
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
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 be a
On Wed, Jun 3, 2009 at 5:01 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
>> 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 wo
On Wed, Jun 3, 2009 at 5:14 PM, Dave Page 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 pgsql-hackers maili
Andres Freund 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 all in profiles.
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 writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
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
p
Hi,
On 06/03/2009 06:21 PM, Tom Lane wrote:
Andres Freund 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 operati
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
avail
Tom Lane wrote:
Gevik Babakhani 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
Andres Freund 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 additional
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 hardlink
Andrew Dunstan 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 bit worried
about
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freund 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 fro
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 Herrerahttp://www.C
Andres Freund 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!) without very high stati
Tatsuo Ishii 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 out of ran
Markus Wanner wrote:
> Hi,
>
> Quoting "David E. Wheeler" :
>> 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.
Andrew Dunstan wrote:
>
>
> Dave Page wrote:
>> On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
>> 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 w
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 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
http://archives.postgresql.org/pgsql-co
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
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 wor
Josh Berkus 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
> want to backpa
Magnus Hagander 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, since I ob
Tom Lane wrote:
> Magnus Hagander 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 i
Hiroshi Inoue 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 this at
all.
Tatsuo Ishii 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 contain
> lexemes, i
"Kevin Grittner" writes:
> Andres Freund 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 mu
Gregory Stark 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 aforementioned stati
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 n
Gregory Stark 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 to 85 ms once the st
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:
h
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 writes:
>
>
> > What is , and why is it being imported by the Perl headers?
>
> It seems that problem is with Perl. It includes sys/mode.h. The new
> change for gcc 4.2 is tha
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
wrote:
> Gregory Stark 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
Robert Haas 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
> doesn't really matt
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 don
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,
un
Emmanuel Cecchet 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 transaction is don
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
2009/
"Kevin Grittner" 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 behavior seems so
> ou
Robert Haas writes:
> On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
> 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 when we were last looking at
> default_st
Tom Lane wrote:
Emmanuel Cecchet 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 tran
Emmanuel Cecchet 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 pgsql-hackers mailin
> 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
On 06/03/2009 07:05 PM, Kevin Grittner wrote:
Andres Freund 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 le
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 i
Greg Stark 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 unlikely to be most-common value
Tatsuo Ishii 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 can't duplicate
On Wed, 3 Jun 2009, Tom Lane wrote:
Tatsuo Ishii 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
1 - 100 of 117 matches
Mail list logo
