Andres Freund-3 wrote
On 2013-11-04 11:27:33 -0500, Robert Haas wrote:
On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire lt;
klaussfreire@
gt; wrote:
Such a thing would help COPY, so maybe it's worth a look
I have little doubt that a deferred insertion buffer of some kind
could help
Simon Riggs wrote
Everybody on this thread is advised to look closely at Min Max indexes
before starting any further work.
MinMax will give us access to many new kinds of plan, plus they are
about as close to perfectly efficient, by which I mean almost zero
overhead, with regard to inserts
Arul Shaji Arulappan wrote:
Attached is a patch that implements the first set of changes discussed
in this thread originally. They are:
(i) Implements NCHAR/NVARCHAR as distinct data types, not as synonyms so
that:
- psql \d can display the user-specified data types.
-
On 5 November 2013 08:32, Leonardo Francalanci m_li...@yahoo.it wrote:
Simon Riggs wrote
Everybody on this thread is advised to look closely at Min Max indexes
before starting any further work.
MinMax will give us access to many new kinds of plan, plus they are
about as close to perfectly
Hello,
With this index, you will get a different plan like this,
Exactly my point, can we look at making windowing functions
smart and make use of available indexes?
I might have guessed..
Does this satisfies your needs?
Not exactly. If I have missed to mention, this is not
Simon Riggs wrote
Minmax indexes seem to surprise many people, so broad generalisations
aren't likely to be useful.
I think the best thing to do is to publish some SQL requests that
demonstrate in detail what you are trying to achieve and test them
against minmax indexes. That way we can
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
---
configure.in | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/configure.in b/configure.in
index a4baeaf..7c5b3ce 100644
--- a/configure.in
+++
On 5 November 2013 09:57, Leonardo Francalanci m_li...@yahoo.it wrote:
Simon Riggs wrote
Minmax indexes seem to surprise many people, so broad generalisations
aren't likely to be useful.
I think the best thing to do is to publish some SQL requests that
demonstrate in detail what you are
Simon Riggs wrote
On 5 November 2013 09:57, Leonardo Francalanci lt;
m_lists@
gt; wrote:
While I do believe in testing (since In theory there is no difference
between theory and practice. In practice there is), I would like to know
the properties of the minmax index before trying it.
What
Hi
When PG crashes or the computer turned down unexpectedly, next time
postmaster
starts up, it does the crash recovery, actually redo xlog records, vacuum,
etc.
What module is responsible for crash recovery?
Regards,
Soroosh Sardari
On 05.11.2013 13:21, Soroosh Sardari wrote:
When PG crashes or the computer turned down unexpectedly, next time
postmaster
starts up, it does the crash recovery, actually redo xlog records, vacuum,
etc.
What module is responsible for crash recovery?
See src/backend/access/transam/xlog.c. The
On 05.11.2013 12:22, Oskari Saarenmaa wrote:
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
Hmm, that would mean that a build from git checkout REL9_3_1 produces
a different binary than one built from
From: Albe Laurenz laurenz.a...@wien.gv.at
If I understood the discussion correctly the use case is that
there are advantages to having a database encoding different
from UTF-8, but you'd still want sume UTF-8 columns.
Wouldn't it be a better design to allow specifying the encoding
per column?
MauMau wrote:
From: Albe Laurenz laurenz.a...@wien.gv.at
If I understood the discussion correctly the use case is that
there are advantages to having a database encoding different
from UTF-8, but you'd still want sume UTF-8 columns.
Wouldn't it be a better design to allow specifying the
On Tue, Nov 5, 2013 at 6:57 AM, Leonardo Francalanci m_li...@yahoo.it wrote:
Simon Riggs wrote
Minmax indexes seem to surprise many people, so broad generalisations
aren't likely to be useful.
I think the best thing to do is to publish some SQL requests that
demonstrate in detail what you
Hello,
Please find attached pg_stat_statements-identification-v9.patch.
I have tried to address the following review comments
1. Use version PGSS_TUP_V1_2
2.Fixed total time being zero
3. Remove 'session_start' from the view and use point release number
to generate queryid
4. Hide only queryid and
On Mon, Nov 4, 2013 at 8:00 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/04/2013 09:55 PM, Robert Haas wrote:
I continue to think that this syntax is misguided. For SELECT and
DELETE there is only read-side security, and for INSERT there is only
write-side security, so that's OK as far
On Mon, Nov 4, 2013 at 8:46 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/04/2013 11:17 PM, Robert Haas wrote:
I'd still like to here what's wrong with what I said here:
http://www.postgresql.org/message-id/ca+tgmoyr1phw3x9vnvuwdcfxkzk2p_jhtwc0fv2q58negcx...@mail.gmail.com
For me, just
On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch n...@leadboat.com wrote:
On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote:
Remove internal uses of CTimeZone/HasCTZSet.
This changed
Hello.
Examining pg_dump sources recently I've found that different exit
procedure used for the same situations.
A quick example from pg_dump.c:
if (dataOnly schemaOnly)
exit_horribly(NULL, options -s/--schema-only and
-a/--data-only cannot be used together\n);
* Robert Haas (robertmh...@gmail.com) wrote:
Now maybe that's fine. But given that, I think it's pretty important
that we get the syntax right. Because if you're adding a feature
primarily to add a more convenient syntax, then the syntax had better
actually be convenient.
I agree that we
On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
On 05.11.2013 12:22, Oskari Saarenmaa wrote:
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
Hmm, that would mean that a build from git checkout REL9_3_1
On Tue, Nov 5, 2013 at 2:05 PM, Oskari Saarenmaa o...@ohmu.fi wrote:
I can see some value in that kind of information, ie. knowing what
patches a binary was built with, but this would only solve the
problem for git checkouts. Even for a git checkout, the binaries
won't be automatically updated
David Rowley escribió:
In this case how does Postgresql know that attnum 3 is the 2nd user column
in that table? Unless I have misunderstood something then there must be
some logic in there to skip dropped columns and if so then could it not
just grab the attphynum at that location? then just
Claudio Freire wrote
Min-max indexes always require a sequential scan of the min-max index
itself when querying.
I'm worried about the number of heap pages that will be scanned.
My understanding is that given the random input, the index will
not be selective enough, and will end up requiring a
Oskari Saarenmaa o...@ohmu.fi writes:
On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
I can see some value in that kind of information, ie. knowing what
patches a binary was built with, but this would only solve the
problem for git checkouts. Even for a git checkout, the
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch n...@leadboat.com wrote:
I was prepared to suppose that no substantial clientele relies on the
to_char() TZ format code expanding to blank, the other behavior that
changed
with this patch. It's more of a
On Tue, Nov 5, 2013 at 11:28 AM, Leonardo Francalanci m_li...@yahoo.it wrote:
I get 9000 pages for 49 values out of 50... which means scanning 90% of
the table.
Either my sql is not correct (likely), or my understanding of the minmax
index is
not correct (even more likely), or the minmax
Claudio Freire wrote
real data isn't truly random
Well, let's try normal_rand???
create table t1 as select trunc(normal_rand(100, 50, 3)) as n,
generate_series(1, 100) as i;
with cte as
(select min(n) as minn, max(n) as maxn, i/100 from t1 group by i/100),
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I agree with Heikki that this is basically useless. Most of my builds are
from git + uncommitted changes, so telling me what the top commit was has
no notable value.
The focus of this change would really be, imv anyway, for more casual
PG developers,
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
So basically, this
would only be useful to people building production servers from random git
pulls from development or release-branch mainline. How many people really
do that, and should we inconvenience
On 11/05/2013 10:32 AM, Stephen Frost wrote:
All-in-all, I'm not super excited about this but I also wouldn't mind,
so while not really a '+1', I'd say '+0'. Nice idea, if it isn't
painful to deal with and maintain.
I doubt it's buying us anything worth having. What's more, it
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What about, say, a configure option to add a
user-specified string to the version() result?
I quite like that idea, personally. Folks who care about it being a git
tag could then trivially get that also.
Thanks,
Stephen
Hi,
(Coming back to this now)
On 2013-10-28 21:55:22 +0100, Andres Freund wrote:
The list I have previously suggested was:
* pg_atomic_load_u32(uint32 *)
* uint32 pg_atomic_store_u32(uint32 *)
To be able to write code without spreading volatiles all over while
making it very clear that
On 11/05/2013 10:53 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What about, say, a configure option to add a
user-specified string to the version() result?
I quite like that idea, personally. Folks who care about it being a git
tag could then trivially get that also.
On Tue, Nov 5, 2013 at 9:01 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Now maybe that's fine. But given that, I think it's pretty important
that we get the syntax right. Because if you're adding a feature
primarily to add a more convenient
This can be used to tag custom built packages with an extra version string
such as the git describe id or distribution package release version.
Based on pgsql-hackers discussion:
http://www.postgresql.org/message-id/20131105102226.ga26...@saarenmaa.fi
Signed-off-by: Oskari Saarenmaa o...@ohmu.fi
Back at
http://www.postgresql.org/message-id/520d221e.2060...@gmail.com
there was a complaint about strange behavior of a query that looks
basically like this:
SELECT ...
FROM
(SELECT ... ,
( SELECT ...
ORDER BY random()
LIMIT 1
)
On Tue, Nov 5, 2013 at 12:25 AM, Leonardo Francalanci m_li...@yahoo.itwrote:
Andres Freund-3 wrote
On 2013-11-04 11:27:33 -0500, Robert Haas wrote:
On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire lt;
klaussfreire@
gt; wrote:
Such a thing would help COPY, so maybe it's worth a look
I'm wondering what type of index would work for this as it is a volatile
function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
wouldn't be possible or worth doing. It seems to me that all functions in
the select part of the statement could be calculated at the end of the
query
On Tue, Nov 5, 2013 at 6:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Oskari Saarenmaa o...@ohmu.fi writes:
On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
I can see some value in that kind of information, ie. knowing what
patches a binary was built with, but this would
On Tue, Nov 5, 2013 at 12:22 PM, Leonardo Francalanci m_li...@yahoo.it wrote:
Claudio Freire wrote
you haven't really
analyzed update cost, which is what we were talking about in that last
post.
I don't care for a better update cost if the cost to query is a table scan.
Otherwise, I'll just
On 04.11.2013 23:44, Alexander Korotkov wrote:
On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
Attached version of patch is debugged. I would like to note that number of
bugs was low and it wasn't very hard to debug. I've rerun tests on it. You
can see that
Claudio Freire wrote
Well, of course, they're not magic pixie dust.
Of course they aren't. I think they can make a difference in a sequential
input scenario. But I'm not the one who said that they are fit to
solve the problems me and other people are talking about in this thread.
Claudio
Jeff Janes wrote
Some experiments I did a few years ago showed that applying sorts to the
data to be inserted could be helpful even when the sort batch size was as
small as one tuple per 5 pages of existing index. Maybe even less.
Cool!!! Do you have any idea/hint on how I could try and
On Tue, Nov 5, 2013 at 2:52 PM, Leonardo Francalanci m_li...@yahoo.it wrote:
Jeff Janes wrote
Some experiments I did a few years ago showed that applying sorts to the
data to be inserted could be helpful even when the sort batch size was as
small as one tuple per 5 pages of existing index.
Noah,
Also, JSON -- Text seems to be missing from the possible binary
conversions. That's a TODO, I suppose.
Only json -- text, not json -- text. Note that you can add the cast
manually if you have an immediate need.
Huh? Why would text -- JSON require a physical rewrite? We have to
On Tue, Nov 05, 2013 at 10:00:15AM -0800, Josh Berkus wrote:
Noah,
Also, JSON -- Text seems to be missing from the possible binary
conversions. That's a TODO, I suppose.
Only json -- text, not json -- text. Note that you can add the cast
manually if you have an immediate need.
We've had a couple of complaints about the error message that's thrown
for the case where you try to copy-and-modify a window definition that
includes a frame clause:
http://www.postgresql.org/message-id/200911191711.najhbped009...@wwwmaster.postgresql.org
Joe Love j...@primoweb.com writes:
I'm wondering what type of index would work for this as it is a volatile
function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
wouldn't be possible or worth doing. It seems to me that all functions in
the select part of the statement
On Tue, Nov 5, 2013 at 11:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joe Love j...@primoweb.com writes:
I'm wondering what type of index would work for this as it is a volatile
function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
wouldn't be possible or worth doing. It
Noah,
That's all true, but the system has no concept like this cast validates the
data, never changing it. We would first need to add metadata supporting such
a concept. On the other hand, create cast (json as text) without function;
leans only on concepts the system already knows.
Yeah,
On 2013-11-05 11:15:29 -0800, Josh Berkus wrote:
Noah,
That's all true, but the system has no concept like this cast validates the
data, never changing it. We would first need to add metadata supporting
such
a concept. On the other hand, create cast (json as text) without
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
What about just unowning the smgr entry with
if (rel-rd_smgr != NULL)
smgrsetowner(NULL, rel-rd_smgr)
when closing the fake relcache entry?
That shouldn't require any further changes than changing the comment in
smgrsetowner() that this
This patch implements the following TODO item:
Split out pg_resetxlog output into pre- and post-sections
http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
On execution of pg_resetxlog using the option -n
1. It will
Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-02 17:05:24 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Also attached is 0004 which just adds a heap_lock() around a
newly created temporary table in the matview code which
shouldn't be required for
On 2013-11-05 11:56:25 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-02 17:05:24 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Also attached is 0004 which just adds a heap_lock() around a
newly created temporary table in
On 2013-11-05 12:21:23 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com
Looks fine to me
Any thoughts on whether this should be back-patched to 9.3? I can
see arguments both ways, and don't have a particularly strong
feeling one way or the other.
Hehe. I was wondering
Hi,
There frequently have been bugs where (heap|relation|index)_open(NoLock)
was used without a previous locks which in some circumstances is an easy
mistake to make and which is hard to notice.
The attached patch adds --use-cassert only WARNINGs against doing so:
Add cassert-only checks
I wrote:
I noticed this while poking at the variadic-aggregates issue:
regression=# create function nth_value_def(anyelement, integer = 1) returns
anyelement language internal window immutable strict as 'window_nth_value';
CREATE FUNCTION
regression=# SELECT nth_value_def(ten) OVER
From: Albe Laurenz laurenz.a...@wien.gv.at
I looked into the Standard, and it does not have NVARCHAR.
The type is called NATIONAL CHARACTER VARYING, NATIONAL CHAR VARYING
or NCHAR VARYING.
OUch, that's just a mistake in my mail. You are correct.
I guess that the goal of this patch is to
Andres Freund and...@2ndquadrant.com writes:
There frequently have been bugs where (heap|relation|index)_open(NoLock)
was used without a previous locks which in some circumstances is an easy
mistake to make and which is hard to notice.
The attached patch adds --use-cassert only WARNINGs
On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
There frequently have been bugs where (heap|relation|index)_open(NoLock)
was used without a previous locks which in some circumstances is an easy
mistake to make and which is hard to notice.
The
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
If we're sufficiently worried by this type of bug, ISTM we'd be better off
just disallowing heap_open(NoLock). At the time we invented that, every
lock request went to shared memory; but now that we
Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-05 12:21:23 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com
Looks fine to me
Any thoughts on whether this should be back-patched to 9.3? I
can see arguments both ways, and don't have a particularly
strong feeling one
On 2013-11-05 16:45:49 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
If we're sufficiently worried by this type of bug, ISTM we'd be better off
just disallowing heap_open(NoLock). At the time we invented that, every
lock
On 2013-11-05 22:35:41 +0100, Andres Freund wrote:
We could relatively easily optimize that to a constant factor by just
iterating over the possible lockmodes. Should only take a couple more
lines.
On that note, any chance you remember why you increased MAX_LOCKMODE by
2 to 10 back in 2001
On 11/5/13, 1:04 AM, Arulappan, Arul Shaji wrote:
Implements NCHAR/NVARCHAR as distinct data types, not as synonyms
If, per SQL standard, NCHAR(x) is equivalent to CHAR(x) CHARACTER SET
cs, then for some cs, NCHAR(x) must be the same as CHAR(x).
Therefore, an implementation as separate data
Andres Freund and...@2ndquadrant.com writes:
On that note, any chance you remember why you increased MAX_LOCKMODE by
2 to 10 back in 2001 although AccessExclusiveLock is 8? The relevant
commit is 4fe42dfbc3bafa0ea615239d716a6b37d67da253 .
Probably because it seemed like a round number, which 9
I wrote:
Attached is a proposed patch against HEAD that fixes this by supporting
default arguments properly for window functions. In passing, it also
allows named-argument notation in window function calls, since that's
free once the other thing works (because the same subroutine fixes up
On 2013-11-05 17:19:21 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On that note, any chance you remember why you increased MAX_LOCKMODE by
2 to 10 back in 2001 although AccessExclusiveLock is 8? The relevant
commit is 4fe42dfbc3bafa0ea615239d716a6b37d67da253 .
Ian Lawrence Barwick barw...@gmail.com writes:
2013/9/10 Bruce Momjian br...@momjian.us:
I still see that weird behavior in git head:
pgdevel=# \s history.txt
Wrote history to file ./history.txt.
pgdevel=# \s /tmp/history.txt
Wrote history to file .//tmp/history.txt.
pgdevel=# \cd /tmp
On Tue, Nov 5, 2013 at 4:29 PM, Oskari Saarenmaa o...@ohmu.fi wrote:
This can be used to tag custom built packages with an extra version string
such as the git describe id or distribution package release version.
Could you attach a proper patch to your email and register it to the
next commit
On Tue, Nov 5, 2013 at 5:30 PM, Claudio Freire klaussfre...@gmail.comwrote:
Maybe there's value in minmax indexes for sequential data, but not for
random data, which is the topic of this thread.
Well, of course, they're not magic pixie dust.
But is your data really random? (or normal?)
Greg Stark escribió:
I think minmax indexes are more akin to bitmap indexes. They will be very
effective for columns with low-cardinality, especially for columns that are
very clustered. In the extreme if all the values in some regions of the
table are the same then minmax indexes would be
Andres,
There's zap chance of doing anything for 9.3, this would require quite a
bit of code in tablecmds.c and that surely isn't going to happen in the
backbranches.
Oh, sure, I was thinking of a workaround.
Actually, being able to separate need to check contents from need to
rewrite values
Peter Eisentraut pete...@gmx.net writes:
Attached is a patch that
- Adds a .gitattributes file to configure appropriate whitespace checks
for git diff --check.
- Cleans up all whitespace errors found in this way in existing code.
Most of that is in files not covered by pgindent, some in new
Peter Eisentraut wrote:
This makes the entire tree git diff --check clean. After this, future
patches can be inspected for whitespace errors with git diff --check,
something that has been discussed on occasion.
+1 to this, and also +1 to Tom's suggestion of making it more strongly
enforced.
On Thu, Oct 31, 2013 at 8:22 PM, Noah Misch n...@leadboat.com wrote:
CommitTransaction() and AbortTransaction() both do much work, and large
portions of that work either should not or must not throw errors. An error
during either function will, as usual, siglongjmp() out. Ordinarily,
On 11/05/2013 09:36 PM, Robert Haas wrote:
I haven't studied this patch in detail, but I see why there's some
unhappiness about that code: it's an RLS-specific kluge. Just
shooting from the hip here, maybe we should attack the problem of
making security-barrier views updatable first, as a
On 11/05/2013 09:30 PM, Robert Haas wrote:
So really, there are four cases:
READ
WRITE INSERT
WRITE UPDATE
WRITE DELETE
Isn't READ similarly divisible into READ SELECT, READ UPDATE, and READ DELETE?
Not in my opinion. No matter what the command, the read side is all
about having some way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/05/2013 10:01 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Now maybe that's fine. But given that, I think it's pretty
important that we get the syntax right. Because if you're adding
a feature primarily to add a
82 matches
Mail list logo
