On Fri, Sep 20, 2013 at 12:48 AM, Peter Eisentraut pete...@gmx.net wrote:
Something is weird in your latest patch. The header is:
diff -u -r b/postgresql/doc/src/sgml/config.sgml
a/postgresql/doc/src/sgml/config.sgml
--- b/postgresql/doc/src/sgml/config.sgml 2013-09-09
On Thu, Sep 19, 2013 at 11:32 AM, Fujii Masao-2 [via PostgreSQL]
ml-node+s1045698n5771565...@n5.nabble.com wrote:
On Thu, Sep 19, 2013 at 2:25 PM, samthakur74 [hidden
email]http://user/SendEmail.jtp?type=nodenode=5771565i=0
wrote:
I got the segmentation fault when I tested the case where
David Rowley wrote:
I moved the source around and I've patched against it again. New patch
attached.
Thank you, marked as ready for committer.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas robertmh...@gmail.com wrote:
Marking this as Ready for committer.
Thanks a ton for reviewing the patch.
I rewrote the comments for this patch and fixed the incorrect
formatting in parse_relation.c. It used spaces instead of tabs, which
is why
On Fri, Sep 20, 2013 at 12:57 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas robertmh...@gmail.com wrote:
Marking this as Ready for committer.
Thanks a ton for reviewing the patch.
I rewrote the comments for this patch and fixed the incorrect
On 09/19/2013 11:40 PM, Dimitri Fontaine wrote:
Vik Fearing vik.fear...@dalibo.com writes:
I don't know if this has been discussed before, a cursory search of the
archives didn't turn up anything interesting. I perhaps didn't put in
the right keywords.
For others not to spend too much time
On Fri, Sep 20, 2013 at 1:11 AM, Daniel Farina dan...@fdr.io wrote:
I think the n-call underestimation propagation may not be quite precise for
various detailed reasons (having to do with 'sticky' queries) and to make it
precise is probably more work than it's worth. And, on more reflection,
On 16 September 2013 03:43, Marko Tiikkaja ma...@joh.to wrote:
On 2013-09-15 23:23, Jaime Casanova wrote:
If using ASSERT as keyword is not acceptable, not that i agree but in
case.
What about using RAISE EXCEPTION WHEN (condition)
I was going to suggest the same idea: Extend RAISE syntax
On Fri, Sep 20, 2013 at 08:58:53AM +0900, Tatsuo Ishii wrote:
For example, CREATE TABLE t1(t NCHAR(10)) will succeed if NCHAR is
UTF-8 and database encoding is UTF-8. Even succeed if NCHAR is
SHIFT-JIS and database encoding is UTF-8 because there is a conversion
between UTF-8 and SHIFT-JIS.
Attached patch combines documentation patch and source-code patch.
I have had a stab at reviewing the documentation. Have a look.
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1749,6 +1749,50 @@ include 'filename'
/listitem
/varlistentry
+
On 9/20/13 12:09 PM, Amit Khandekar wrote:
On 16 September 2013 03:43, Marko Tiikkaja ma...@joh.to wrote:
I think it would be extremely surprising if a command like that got
optimized away based on a GUC, so I don't think that would be a good idea.
In pl_gram.y, in the rule stmt_raise,
On Thu, Sep 19, 2013 at 06:31:38PM -0400, Steve Singer wrote:
I think there is agreement that better (as in more obscure)
operators than === and !== need to be picked and we need to find a
place in the user-docs to warn users of the behaviour of this
operators. Hannu has proposed
*==*
On 9/19/13 9:09 PM, Robert Haas wrote:
Personally, I'm pretty skeptical about the value of adding dedicated
syntax for this. I mean, I'll be the first to admit that PL/pgsql is
a clunky and awkward language. But somebody's always proposing
something that they think will make it better, and I
Okay, are you adding this to the september commitfest?
OK, I've done that. I think that it's too late for 9.3.
+1 for idea.
I have tested patch and got surprising results with Cent-OS
Patch is working fine for Cent-OS 6.2 and RHEL 6.3
But is is giving problem on Cent-OS 6.3 (tab
Hi,
On 2013-09-19 12:05:35 -0400, Robert Haas wrote:
No question. I'm not saying that that optimization shouldn't go in
right after the main patch does, but IMHO right now there are too many
things going in the 0004 patch to discuss them all simultaneously.
I'd like to find a way of
Hi,
Prompted by Andres Freund's comments on my Freezing without Write I/O
patch, I realized that there's there's an existing bug in the way
predicate locking handles freezing (or rather, it doesn't handle it).
When a tuple is predicate-locked, the key of the lock is ctid+xmin.
However, when
Hi,
On 2013-09-19 11:44:34 -0400, Robert Haas wrote:
On Wed, Sep 18, 2013 at 1:42 PM, Andres Freund and...@2ndquadrant.com wrote:
--- /dev/null
+++ b/src/backend/storage/ipc/dsm.c
+#define PG_DYNSHMEM_STATE_FILE PG_DYNSHMEM_DIR
/state
+#define
Hi,
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is ctid+xmin. However,
when a tuple is frozen, its xmin is changed to FrozenXid. That effectively
invalidates any predicate lock on the tuple, as checking for a lock on the
same
On 2013-09-20 13:53:04 +0200, Andres Freund wrote:
Hi,
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is ctid+xmin. However,
when a tuple is frozen, its xmin is changed to FrozenXid. That effectively
invalidates any
Here is a review of the pg_sleep(INTERVAL) patch version 1:
- patch applies cleanly on current head
- the function documentation is updated and clear
- the function definition relies on a SQL function
to call the underlying pg_sleep(INT) function
I'm fine with this, especially as if
On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja ma...@joh.to wrote:
The issue of how this is spelled is somewhat secondary for me. I
think ASSERT is probably as good as anything. But let's not kid
ourselves: even reserving this word only in PL/pgsql WILL break things
for some users, and
On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
I think I'd prefer a GUC that allows specifying multiple directories
that are searched in order to a single symlinked
On 2013-09-20 08:06:56 -0400, Robert Haas wrote:
On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund and...@2ndquadrant.com wrote:
Because I want to specify multiple paths. E.g. one with modules for a
specific postgres version, one for the cluster and one for my
development directory.
Now we
On Fri, Sep 20, 2013 at 8:10 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-20 08:06:56 -0400, Robert Haas wrote:
On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund and...@2ndquadrant.com
wrote:
Because I want to specify multiple paths. E.g. one with modules for a
specific postgres
On Fri, Sep 20, 2013 at 3:41 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Sep 20, 2013 at 12:57 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas robertmh...@gmail.com wrote:
Marking this as Ready for committer.
Thanks a ton for reviewing
* Kevin Grittner (kgri...@ymail.com) wrote:
... like
just refreshing a view so that the new contents are the same as
what you would see if you re-ran the query defining the matview.
I've heard this notion a few times of wanting to make sure that what you
get from running the query matches the
On Thu, Sep 19, 2013 at 6:27 PM, Ants Aasma a...@cybertec.at wrote:
I'm tackling similar issues in my patch. What I'm thinking is that we should
change our existing supposedly atomic accesses to be more explicit and make
the API compatible with C11 atomics[1]. For now I think the changes should
Robert Haas robertmh...@gmail.com writes:
So... our usual comma-separated GUC syntax? Empty means no extra
places to search.
Sounds pretty good to me.
The only advantage of using an initdb place would have been the
opportunity to actually register modules and WAL log that step so that
the
Steve Singer st...@ssinger.info wrote:
On 09/12/2013 06:27 PM, Kevin Grittner wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
Here is attempt at a
Hi,
I agree with most of what you said - I think that's a littlebit too much
change for too little benefit.
On 2013-09-20 08:32:29 -0400, Robert Haas wrote:
Personally, I think the biggest change that would help here is to
mandate that spinlock operations serve as compiler fences. That would
On 2013-09-20 14:35:31 +0200, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
So... our usual comma-separated GUC syntax? Empty means no extra
places to search.
+1.
The only advantage of using an initdb place would have been the
opportunity to actually register modules
On Fri, Sep 20, 2013 at 8:40 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-20 08:32:29 -0400, Robert Haas wrote:
Personally, I think the biggest change that would help here is to
mandate that spinlock operations serve as compiler fences. That would
eliminate the need for scads of
2013/9/20 Robert Haas robertmh...@gmail.com
On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja ma...@joh.to wrote:
The issue of how this is spelled is somewhat secondary for me. I
think ASSERT is probably as good as anything. But let's not kid
ourselves: even reserving this word only in
On 09/20/2013 01:59 PM, Robert Haas wrote:
The other part of the problem is that the language isn't designed from
the beginning to be extensible. In Perl, for example, they chose to
mark variables with a leading $, @, or % and functions with a leading
. That last marking has largely fallen
On Fri, Sep 20, 2013 at 3:40 PM, Sameer Thakur samthaku...@gmail.comwrote:
Attached patch combines documentation patch and source-code patch.
I have had a stab at reviewing the documentation. Have a look.
Thanks.
Attached patch implements suggestions in documentation.
But comments from
Robert Haas escribió:
On Sun, Sep 15, 2013 at 10:51 AM, Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
It shouldn't be in the commit fest if it has no patch.
What should I do if my goal is to
On Fri, Sep 20, 2013 at 5:53 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 20, 2013 at 3:41 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Sep 20, 2013 at 12:57 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas
Steve,
Thanks for providing a summary.
* Steve Singer (st...@ssinger.info) wrote:
The arguments for this patch are
* We want the materialized view to return the same value as would be
returned if the query were executed directly. This not only means
that the values should be the same
On Fri, Sep 20, 2013 at 9:43 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Handling for OID is not clear, shall we allow it or not in check
constraint?
In my current patch OID will not be allowed in check constraint.
I vote for allowing it.
--
Robert Haas
EnterpriseDB:
Stephen Frost sfr...@snowman.net wrote:
* Kevin Grittner (kgri...@ymail.com) wrote:
... like
just refreshing a view so that the new contents are the same as
what you would see if you re-ran the query defining the matview.
I've heard this notion a few times of wanting to make sure that what
On Fri, Sep 20, 2013 at 7:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 20, 2013 at 9:43 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Handling for OID is not clear, shall we allow it or not in check
constraint?
In my current patch OID will not be allowed in check
Stephen Frost sfr...@snowman.net wrote:
The issue here is that we're trying to make the mat view look
like what the query would do when run at the same time, which is
a bit of a losing battle, imv.
If we're not doing that, I don't see the point of matviews.
--
Kevin Grittner
EDB:
On Friday, September 20, 2013, Kevin Grittner wrote:
Stephen Frost sfr...@snowman.net javascript:; wrote:
The issue here is that we're trying to make the mat view look
like what the query would do when run at the same time, which is
a bit of a losing battle, imv.
If we're not doing
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is ctid+xmin.
However, when a tuple is frozen, its xmin is changed to FrozenXid. That
effectively
invalidates any predicate lock on the
On 20 September 2013 11:29, Samrat Revagade revagade.sam...@gmail.com wrote:
Okay, are you adding this to the september commitfest?
OK, I've done that. I think that it's too late for 9.3.
+1 for idea.
I have tested patch and got surprising results with Cent-OS
Patch is working fine
Stephen Frost sfr...@snowman.net wrote:
On Friday, September 20, 2013, Kevin Grittner wrote:
Stephen Frost sfr...@snowman.net wrote:
The issue here is that we're trying to make the mat view look
like what the query would do when run at the same time, which
is a bit of a losing battle, imv.
On 2013-09-20 08:54:26 -0400, Robert Haas wrote:
On Fri, Sep 20, 2013 at 8:40 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-20 08:32:29 -0400, Robert Haas wrote:
Personally, I think the biggest change that would help here is to
mandate that spinlock operations serve as compiler
* Kevin Grittner (kgri...@ymail.com) wrote:
The result of this is that with the patch, an incremental refresh
of a matview will always match what the query returned at the time
it was run (there is no *correctness* problem) but if someone uses
a query with non-deterministic results they may
On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
I'm trying to figure out why that's a perfectly acceptable solution for
users running views with GROUP BYs, but apparently it isn't sufficient
for mat views?
Err, because users wrote a GROUP BY? They haven't (neccessarily) in the
cases of the
Stephen Frost sfr...@snowman.net wrote:
* Kevin Grittner (kgri...@ymail.com) wrote:
The result of this is that with the patch, an incremental refresh
of a matview will always match what the query returned at the time
it was run (there is no *correctness* problem) but if someone uses
a query
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
I'm trying to figure out why that's a perfectly acceptable solution for
users running views with GROUP BYs, but apparently it isn't sufficient
for mat views?
Err, because users wrote a
Andres Freund escribió:
Hi,
On 2013-09-19 14:42:19 +0300, Heikki Linnakangas wrote:
On 18.09.2013 16:22, Andres Freund wrote:
* Why can we do a GetOldestXmin(allDbs = false) in
BeginXidLSNRangeSwitch()?
Looks like a bug. I think I got the arguments backwards, was supposed to be
On 2013-09-20 11:05:06 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
I'm trying to figure out why that's a perfectly acceptable solution for
users running views with GROUP BYs, but apparently it isn't
* Kevin Grittner (kgri...@ymail.com) wrote:
Stephen Frost sfr...@snowman.net wrote:
You mean 'at the time of the incremental refresh', right? Yet that may
or may not match running that query directly by an end-user as the plan
that a user might get for the entire query could be different
On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund and...@2ndquadrant.com wrote:
The reason I suggested keeping track of the xids of unremovable tuples
is that the current logic doesn't handle that at all. We just
unconditionally set n_dead_tuples to zero after a vacuum even if not a
single row
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-09-20 11:05:06 -0400, Stephen Frost wrote:
Sure; my thinking was going back to what Hannu had suggested where we
have a mechanism to see if the value was updated (using xmin or similar)
and then update it in the mat view in that case,
Pavel Stehule escribió:
PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is not
too bad, and one new specialized statement doesn't kill us. A proposed
functionality is often used and we have not tools (macros) how to implement
it simply.
we support a conditions for few
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
I think we should go through the various implementations and make sure
they are actual compiler barriers and then change the documented policy.
From a quick look
* S_UNLOCK for PPC isn't a compiler barrier
* S_UNLOCK for MIPS isn't a compiler
2013/9/20 Alvaro Herrera alvhe...@2ndquadrant.com
Pavel Stehule escribió:
PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is
not
too bad, and one new specialized statement doesn't kill us. A proposed
functionality is often used and we have not tools (macros) how to
On 2013-09-20 11:30:26 -0400, Robert Haas wrote:
On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund and...@2ndquadrant.com wrote:
The reason I suggested keeping track of the xids of unremovable tuples
is that the current logic doesn't handle that at all. We just
unconditionally set
On Fri, Sep 20, 2013 at 11:51 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-20 11:30:26 -0400, Robert Haas wrote:
On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund and...@2ndquadrant.com
wrote:
The reason I suggested keeping track of the xids of unremovable tuples
is that the
Hi
On Fri, Sep 20, 2013 at 5:11 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
I think we should go through the various implementations and make sure
they are actual compiler barriers and then change the documented policy.
From a quick
On 09/19/2013 02:55 PM, Mike Blackwell wrote:
Interesting. Is this a 9.3 issue? I ran the above against my 9.2.4 server
and got no rows in pg_stats. Did I miss something?
Yeah, that was on 9.3. I think the issue on 9.2 is the same, it just
expresses differently.
--
Josh Berkus
PostgreSQL
Robert,
It probably has to do with the CASE stakind stuff in the definition of
the pg_stats view. Try \d+ pg_stats to see what I mean.
Ok, if this is not a known bug, I'll see if I can work up a fix. No
promises, given the hairyness ...
--
Josh Berkus
PostgreSQL Experts Inc.
On 09/19/2013 04:16 PM, Tatsuo Ishii wrote:
Hi,
I'm Looking for information on our elephant: especially how/why we
chose elephant as our mascot.
What I've been told:
Our first logo was one Jan designed, which was a elephant in a diamond.
While the idea was nice, it looked terrible, so when
Hi,
IMO it's a bug if S_UNLOCK is a not a compiler barrier.
Moreover for volatile remember:
https://www.securecoding.cert.org/confluence/display/seccode/DCL17-C.+Beware+of+miscompiled+volatile-qualified+variables
Who is double checking compiler output? :)
regards
Didier
On Fri, Sep 20, 2013
On 09/20/2013 08:38 AM, Kevin Grittner wrote:
Did you look at the record_eq and record_cmp functions which exist
before this patch? Is there a reason we should do it one way for the
default operators and another way for this alternative?
Do you think we should change record_eq and record_cmp
On Thu, Sep 19, 2013 at 7:58 PM, Tatsuo Ishii is...@postgresql.org wrote:
What about limiting to use NCHAR with a database which has same
encoding or compatible encoding (on which the encoding conversion is
defined)? This way, NCHAR text can be automatically converted from
NCHAR to the
Dimitri Fontaine escribió:
My understanding is that if you choose citext then you don't care at all
about the case, so that the two relations actually yield the same
results for the right definition of same here: the citext one.
For the record, I don't think citext means that the user doesn't
On Thu, Sep 19, 2013 at 6:42 PM, MauMau maumau...@gmail.com wrote:
National character types support may be important to some potential users of
PostgreSQL and the popularity of PostgreSQL, not me. That's why national
character support is listed in the PostgreSQL TODO wiki. We might be losing
On 09/20/2013 11:59 AM, Josh Berkus wrote:
Hackers,
I've been tinkering with a number of table bloat checks, and it occurred
to me that the problm is that these are all approximations based on
overall gross statistics, and as such highly inaccurate.
It seems like would could have ANALYZE,
On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
David Rowley wrote:
I moved the source around and I've patched against it again. New patch
attached.
Thank you, marked as ready for committer.
/*
+ * helper function for processing the format string in
+ *
Hackers,
I've been tinkering with a number of table bloat checks, and it occurred
to me that the problm is that these are all approximations based on
overall gross statistics, and as such highly inaccurate.
It seems like would could have ANALYZE, while sampling from the table,
also check the
On Thu, Sep 19, 2013 at 6:19 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
I think that ship has long since sailed. postgresql.conf has allowed
foo.bar style GUCs
On Fri, Sep 20, 2013 at 7:59 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
- the new function is *not* tested anywhere!
I would suggest simply to replace some pg_sleep(int) instances
by corresponding pg_sleep(interval) instances in the non
regression tests.
- some concerns have
Hello Robert,
- some concerns have been raised that it breaks pg_sleep(TEXT)
which currently works thanks to the implicit TEXT - INT cast.
I would suggest to add pg_sleep(TEXT) explicitely, like:
CREATE FUNCTION pg_sleep(TEXT) RETURNS VOID VOLATILE STRICT AS
$$ select
The file_fdw documentation for the OPTIONS clause references the COPY
command's documentation. In the case of COPY, the value for some options
(e.g. HEADER, OIDS, ...) is optional. While the file_fdw documentation
makes no mention of it, the values for all options are required.
Attached is a
On 9/20/13 2:22 PM, Robert Haas wrote:
I am not keen to introduce support for nchar and nvarchar as
differently-named types with identical semantics.
Similar examples already exist:
- varchar and text: the only difference is the existence of explicit length
limit
- numeric and
Here's the patch I propose to handle renegotiation cleanly. I noticed
in testing that SSL_renegotiate_pending() doesn't seem to actually work
--- if I throw an ereport(FATAL) at the point where I expect the
renegotiation to be complete, it always dies; even if I give it
megabytes of extra traffic
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp wrote:
I create gaussinan distribution pgbench patch that can access
records with gaussian frequency. And I submit this commit fest.
Thanks!
I have moved this to the Open CommitFest, though.
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
I've been tinkering with a number of table bloat checks, and it occurred
to me that the problm is that these are all approximations based on
overall gross statistics, and as such highly inaccurate.
Greg Smith and I discussed some improvements
On Thu, Sep 19, 2013 at 7:43 AM, Andres Freund and...@2ndquadrant.com wrote:
More generally, the thing that bugs me about this approach is that
logical replication is not really special, but what you've done here
MAKES it special. There are plenty of other situations where we are
too
Hello Mitsumasa,
In the general transaction situation, clients access for all records equally is
hard to happen. I think gaussian distribution access patterns are most of
transaction petterns in general. My patch realizes neary this access pattern.
That is great! I was just looking for
On 09/20/2013 02:17 PM, Stephen Frost wrote:
No?
Err, I thought that was one of the things like ANALYZE *did* collect
through the 'live tuples' number?
Nope. live tuples is updated by the stats collector, NOT by analyze.
Also, live vs. dead tuples doesn't tell me how much free *space* is
From: Tatsuo Ishii is...@postgresql.org
What about limiting to use NCHAR with a database which has same
encoding or compatible encoding (on which the encoding conversion is
defined)? This way, NCHAR text can be automatically converted from
NCHAR to the database encoding in the server side thus
From: Valentine Gogichashvili val...@gmail.com
the whole NCHAR appeared as hack for the systems, that did not have it
from
the beginning. It would not be needed, if all the text would be magically
stored in UNICODE or UTF from the beginning and idea of character would be
the same as an idea of
From: Martijn van Oosterhout klep...@svana.org
As far as I can tell the whole reason for introducing NCHAR is to
support SHIFT-JIS, there hasn't been call for any other encodings, that
I can remember anyway.
Could you elaborate on this, giving some info sources?
So rather than this whole
From: Robert Haas robertmh...@gmail.com
I don't think that you'll be able to
get consensus around that path on this mailing list.
I agree that the fact we have both varchar and text feels like a wart.
Is that right? I don't feel varchar/text case is a wart. I think text was
introduced
From: Robert Haas robertmh...@gmail.com
On Thu, Sep 19, 2013 at 7:58 PM, Tatsuo Ishii is...@postgresql.org
wrote:
What about limiting to use NCHAR with a database which has same
encoding or compatible encoding (on which the encoding conversion is
defined)? This way, NCHAR text can be
On Tue, Sep 17, 2013 at 9:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 14, 2013 at 6:27 PM, Peter Geoghegan p...@heroku.com wrote:
Note that today there is no guarantee that the original waiter for a
duplicate-inserting xact to complete will be the first one to get a
second
* Josh Berkus (j...@agliodbs.com) wrote:
Also, live vs. dead tuples doesn't tell me how much free *space* is
available on pages.
I'm not really sure that you'd get much better from ANALYZE than you get
from tracking the inserted/updated/deleted tuples. Collecting that
information when
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
Forgive me if I'm making a leap here, but it seems like what you're
saying is that the semantics of upsert that one might naturally expect
are *arguably* fundamentally impossible, because they entail
potentially locking a row that isn't
On Sat, Sep 21, 2013 at 7:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz laurenz.a...@wien.gv.at
wrote:
David Rowley wrote:
I moved the source around and I've patched against it again. New patch
attached.
Thank you, marked as ready for
For others following along, Pavel Stehule reviewed this on a different thread:
http://www.postgresql.org/message-id/cafj8pravyuhv8x3feewasggvdcijogvlzsavd7rmwn9mw8r...@mail.gmail.com
On Tue, Aug 06, 2013 at 10:47:14AM +0200, Fabien wrote:
Improve pgbench measurements progress report
These
94 matches
Mail list logo
