On 2 March 2013 15:06, Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to
this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a quick look at other DBs to see if there were any other
precedents out there. Oracle was
On 2013-03-01 16:32:19 -0500, Peter Eisentraut wrote:
REINDEX CONCURRENTLY resets the statistics in pg_stat_user_indexes,
whereas plain REINDEX does not. I think they should be preserved in
either case.
Yes. Imo this further suggests that it would be better to switch the
relfilenodes
Dean Rasheed dean.a.rash...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a quick look at other DBs to see if there were any
other precedents
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed from the previous version.
How's this looking for 9.3? On-list discussion seems to have
On 03/02/2013 12:48 AM, Daniel Farina wrote:
On Sun, Feb 24, 2013 at 10:30 PM, Greg Smith g...@2ndquadrant.com wrote:
Attached is some bit rot updates to the checksums patches. The replace-tli
one still works fine
I rather badly want this feature, and if the open issues with the
patch
On 02/23/2013 12:03 AM, Dimitri Fontaine wrote:
Hi,
Please find attached v3 of the Extension Templates patch, with full
pg_dump support thanks to having merged default_full_version, appended
with some regression tests now that it's possible.
There hasn't been visible movement on this work
On 02/09/2013 05:36 PM, Alexander Korotkov wrote:
Your comments and refactoring looks good for me.
This patch is currently flagged as waiting for author. Have you had a
chance to test and examine Jeff's changes in more detail? Would you
consider giving us a summary of the status of this work -
On 02/05/2013 11:53 PM, Amit Kapila wrote:
Performance data for the patch is attached with this mail.
Conclusions from the readings (these are same as my previous patch):
1. With orignal pgbench there is a max 7% WAL reduction with not much
performance difference.
2. With 250 record pgbench
The GIN changes don't seem to have progressed in some time, and some of
the most recent activity
(http://archives.postgresql.org/message-id/50bff89a.7080...@fuzzy.cz)
suggests unconvincing test results.
Is this work considered to be a dead-end - a good idea that didn't work
out in practice? Or do
Hello
I though about any possibility how to reduce a size of this patch.
I see a one solution - if we would not support a detection of multiple
errors - it stops on first error, we can push this code to compilation
stage.
a plpgsql_validator can be overloaded by function
plpgsql_validator(oid,
Craig Ringer cr...@2ndquadrant.com writes:
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed from the previous version.
How's this
On 3 March 2013 13:12, Kevin Grittner kgri...@ymail.com wrote:
Dean Rasheed dean.a.rash...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a
On Sun, Mar 3, 2013 at 6:53 PM, Craig Ringer cr...@2ndquadrant.com wrote:
The GIN changes don't seem to have progressed in some time, and some of
the most recent activity
(http://archives.postgresql.org/message-id/50bff89a.7080...@fuzzy.cz)
suggests unconvincing test results.
Actually,
On Sun, Mar 3, 2013 at 6:37 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/09/2013 05:36 PM, Alexander Korotkov wrote:
Your comments and refactoring looks good for me.
This patch is currently flagged as waiting for author. Have you had a
chance to test and examine Jeff's changes in
In final testing and documentation today, it occurred to me to test
a materialized view with foreign data wrapper. I picked the
file_fdw for convenience, but I think this should work as well with
any other FDW. The idea is to create an MV which mirrors an FDW so
that it can be indexed and
Kevin Grittner kgri...@ymail.com wrote:
test=# explain analyze select word from words order by word - 'caterpiler'
limit 10;
Foreign Scan on words
Total runtime: 218.966 ms
test=# explain analyze select word from wrd order by word - 'caterpiler'
limit 10;
Index Scan using wrd_trgm on
On 03.03.2013 20:06, Kevin Grittner wrote:
The question remains the same, though ... document this usage?
Seems like a good thing to put in an example somewhere.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Works for me, since I haven't been able to find time for it during the
week.
Set aside a couple hours to deal with it this AM, foiled because my
community account is broken. Grrr.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
On 03/03/2013 08:37 PM, Josh Berkus wrote:
Works for me, since I haven't been able to find time for it during the
week.
Set aside a couple hours to deal with it this AM, foiled because my
community account is broken. Grrr.
we might be able to fix this if you could tell us what exactly
On 03/03/2013 11:58 AM, Stefan Kaltenbrunner wrote:
On 03/03/2013 08:37 PM, Josh Berkus wrote:
Works for me, since I haven't been able to find time for it during the
week.
Set aside a couple hours to deal with it this AM, foiled because my
community account is broken. Grrr.
we might be
2013/3/3 Kevin Grittner kgri...@ymail.com:
Rewriting queries using
expressions which match the MV's query to pull from the MV instead
of the underlying tables is the exception. While that is a sexy
feature, and I'm sure one can construct examples where it helps
performance, it seems to me
And here's an updated version of the checksum corruption testing wrapper
script already. This includes an additional safety check that you've
set PGDATA to a location that can be erased. Presumably no one else
would like to accidentally do this:
rm -rf /*
Like I just did.
--
Greg Smith
Nicolas Barbier nicolas.barb...@gmail.com wrote:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Rewriting queries using expressions which match the MV's query
to pull from the MV instead of the underlying tables is the
exception. While that is a sexy feature, and I'm sure one can
construct
Folks,
Where are we with this patch? I'm a bit unclear from the discussion on
whether it passes muster or not. Things seem to have petered out.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Folks,
I'd like to add a new CF status, Pending Discussion. This status
would be used for patches which have long discussions regarding syntax
or difficult functionality on this list which must be resolved before
commit. Examples include SELECT INTO STRICT and Matviews WIP.
Currently these
Craig,
Here's for your summary. I stopped at --echo-hidden, working my way up
from the bottom. Overall, it seems like mostly the patches which are
still in queue are there for good reasons, although there's probably a
few things we could bounce if the authors don't respond in a couple days.
Satoshi Nagayasu sn...@uptime.jp writes:
My goal is to allow specifying a relation/index with several
expressions, 'relname', 'schemaname.relname' and oid in all
pgstattuple functions. pgstatindex() does not accept oid so far.
I have found that the backward-compatibility can be kept
when the
On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner kgri...@ymail.com wrote:
(1) Any DML against the MV would need to be limited to some
context fired by the underlying changes. If we allow changes to
the MV outside of that without it being part of some updateable
MV feature (reversing the
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views even when the
query doesn’t mention them directly, is akin to automatically
using indexes without having to mention them in the query. That
way,
On 12/19/12 6:30 PM, Jeff Davis wrote:
I ran a few tests.
Test 1 - find worst-case overhead for the checksum calculation on write:
Test 2 - worst-case overhead for calculating checksum while reading data
Test 3 - worst-case WAL overhead
What I've done is wrap all of these tests into a shell
Peter,
I tried this patch out. I didn't get as far as testing the
functionality because of errors.
configure/make/make install/make check worked, without asserts. I
believe DF found some errors when he enabled assertions.
When I tried to install the actual transform extensions, though, it
Peter, all:
So in addition to the bugs I encountered in getting this patch to work,
we have a design issue to work out: how to load all of the transform
functions. Each transform depends on an optional datatype (like hstore)
and an optional external language (like plperl), which can be loaded
transforms=# create extension hstore_plperl;
ERROR: could not load library
/home/josh/pg93/lib/postgresql/hstore_plperl.so:
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;
This surprised me, because make
On 1/27/13 2:32 AM, Satoshi Nagayasu wrote:
This patch is intended to improve warning message at
AtEOXact_Buffers(), but I guess another function,
AtProcExit_Buffers(), needs to be modified as well. Right?
Yes, good catch. I've attached an updated patch that does the same sort
of
Nicolas Barbier nicolas.barb...@gmail.com writes:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views even when the
query doesnât mention them directly, is akin to automatically
using indexes without
Andres Freund and...@2ndquadrant.com writes:
On 2013-02-14 20:47:11 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The current behaviour doesn't seem to be a terribly good idea. I propose
to drop the toast table and reset the relfrozenxid in DefineQueryRewrite
in the
There's a much more fundamental reason why this will never happen, which
is that the query planner is not licensed to decide that you only want
an approximate and not an exact answer to your query.
I think it would be worth talking about when someone wants to implement
it. I'd imagine it
Pavel Stehule pavel.steh...@gmail.com writes:
here is patch
Applied, though without the regression test changes, because (a) that
didn't really seem necessary, and (b) I didn't feel like updating
xmlmap_1.out.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Kevin Grittner kgri...@ymail.com wrote:
I'm still working on docs, and the changes related to the syntax
change are still only lightly tested, but as far as I know, all is
complete except for the docs. I'm still working on those and
expect to have them completed late today. I'm posting this
On 13-03-03 06:15 PM, Josh Berkus wrote:
transforms=# create extension hstore_plperl;
ERROR: could not load library
/home/josh/pg93/lib/postgresql/hstore_plperl.so:
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;
This submission didn't have any listed reviewers in the CF app. I added
Zoltan and Andres since both of you went through the usual review steps
and have given lots of feedback.
There are two main sets of issues that keep popping up with this feature:
-The implementation seems too long, at
This (creating the extensions) works fine for me on a Ubuntu 10.x system
H. So I wiped everything out and retried this with clean
directories, and it worked fine. Now I'm not sure how I got the error
in the first place.
Anyway, the feature seems to work as expected:
create function
= Directory vs. single file =
The main reason I've advocated a configuration file directory is to try
and suggest a standard for tool generated config files to co-exist in.
This particular feature doesn't *need* that. But in the long term I was
hoping to have more tools that can write out
Josh Berkus j...@agliodbs.com writes:
I would like to see the name of the directory be conf.d instead of
auto.conf.d though. What's auto about it? Using that word just adds
a source of confusion. The same problem exists with the file name
itself. I was hoping for conf.d/persistent.conf
On 3/3/13 8:34 PM, Tom Lane wrote:
Neither of those names is consistent with any other PGDATA subdirectory
name we use. It should just be config, or perhaps pg_config, though the
latter risks confusion with the tool of the same name.
I'd be just as happy with config/ as the directory name. I
On 3/3/13 4:31 PM, Josh Berkus wrote:
I'd like to add a new CF status, Pending Discussion. This status
would be used for patches which have long discussions regarding syntax
or difficult functionality on this list which must be resolved before
commit.
I made a similar suggestion a few years
On 1/23/13 6:36 AM, Michael Paquier wrote:
The only problem I see is if the same parameter is defined in recovery.conf and
postgresql.conf, is the priority given to recovery.conf?
This sort of thing is what dragged down the past work on this. I don't
really agree with the idea this thread
I thought it was a useful idea anyway, but I could see his point. This
should probably move to Waiting on Author when it happens, presuming
that the person who wrote something is motivated to see the change
committed. (If they weren't, why did they write it?)
Except that the implication of
On 03/03/2013 11:17 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed
On 03/04/2013 01:42 AM, Alexander Korotkov wrote:
This patch only adds one more operator to already committed new
opclass. Tests already cover this case. Without patch corresponding
test leads to sequential scan instead of index scan. However, I can't
see any documentation changes about
On 03/04/2013 01:29 AM, Alexander Korotkov wrote:
Given the activity level I would like to bounce this patch, either as
returned with feedback if you want to take another go at it post-9.3,
or as rejected if you think the idea won't go anywhere. Please let me
know how you think it
On 3/3/13 9:22 AM, Craig Ringer wrote:
Did you get a chance to see whether you can run it in
checksum-validation-and-update-off backward compatible mode? This seems
like an important thing to have working (and tested for) in case of
bugs, performance issues or other unforseen circumstances.
On 03/04/2013 05:35 AM, Josh Berkus wrote:
Craig,
Here's for your summary. I stopped at --echo-hidden, working my way up
from the bottom. Overall, it seems like mostly the patches which are
still in queue are there for good reasons, although there's probably a
few things we could bounce
On Wed, 2013-01-30 at 00:20 +0900, Satoshi Nagayasu wrote:
It seems working well with the latest git master.
I think it's good enough to be committed.
Committed, thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2013 09:58 PM, Stephen Frost wrote:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
But unlike statement_timeout,
with lock_timeout_stmt the statement can still finish after this limit
as it does useful work besides waiting for locks.
On Fri, 2013-03-01 at 14:25 -0500, Noah Misch wrote:
On Mon, Jan 14, 2013 at 06:51:05AM -0500, Peter Eisentraut wrote:
In multi-arch OS installations, using a single foo-config script to
find
libraries is problematic, because you don't know which architecture
it
will point to, and you
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
There are questions about whether this is a good idea, and there's still
discussion ongoing. It doesn't look like it's in a state where we can
confidently say let's include this for 9.3 to me, but I'd like other
viewpoints.
For my part, I
* Craig Ringer (cr...@2ndquadrant.com) wrote:
- Awaiting discussion of syntax:
-- PL/PgSQL STRICT
I agree w/ Josh and Craig that this should probably be bounced- mainly
because we need to get 9.3 properly underway and this looks to continue
to be an area of much discussion.
-- Matview WIP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2013 11:37 AM, Stephen Frost wrote:
- Awaiting discussion of difficult issues:
-- bugfix: --echo-hidden is not supported by \sf statements
Small and difficult - punt it, IMO.
I'd really love to have this properly fixed in 9.3, but I've
On 03/04/2013 11:18 AM, Greg Smith wrote:
On 3/3/13 9:22 AM, Craig Ringer wrote:
Did you get a chance to see whether you can run it in
checksum-validation-and-update-off backward compatible mode? This seems
like an important thing to have working (and tested for) in case of
bugs, performance
Hello All
First, I am new to this great forum.
I have a challenge on my hand as follows. I am a long time libpq user but
have never used the BYTEA data type nor its related functions until now. I
have am writing an interface for a web based application written in C using
libmcrypt and, of
I've gone through all the Server Features entries and partway through the
performance category. So far:
Writable Foreign Tables is waiting for Tom to have a chance to check it out
and do some detailed work on it. Anyone else who wants to step in and help
might be able to improve its chances,
On 03/04/2013 08:27 AM, Josh Berkus wrote:
There's a much more fundamental reason why this will never happen, which
is that the query planner is not licensed to decide that you only want
an approximate and not an exact answer to your query.
I think it would be worth talking about when someone
On 03/04/2013 09:34 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I would like to see the name of the directory be conf.d instead of
auto.conf.d though. What's auto about it? Using that word just adds
a source of confusion. The same problem exists with the file name
itself. I
On 03/04/2013 11:54 AM, Cliff_Bytes wrote:
Hello All
First, I am new to this great forum.
I have a challenge on my hand as follows. I am a long time libpq user but
have never used the BYTEA data type nor its related functions until now. I
have am writing an interface for a web based
On 3/3/13 10:52 PM, Craig Ringer wrote:
I also suspect that at least in the first release it might be desirable
to have an option that essentially says something's gone horribly wrong
and we no longer want to check or write checksums, we want a
non-checksummed DB that can still read our data
On 03/04/2013 12:19 PM, Greg Smith wrote:
On 3/3/13 10:52 PM, Craig Ringer wrote:
I also suspect that at least in the first release it might be desirable
to have an option that essentially says something's gone horribly wrong
and we no longer want to check or write checksums, we want a
While having more docs around extra_float_digits is a great idea, I
don't think the patch really clarifies much.
(Disclaimer: I honestly have only a vague idea of the reasoning behind
extra_float_digits existing in the first place, but perhaps that means
I'm a good target audience for the doc
2013/3/4 Craig Ringer cr...@2ndquadrant.com:
- The SEPostgreSQL patches
I still need to test this on Windows:
SEPostgreSQL is designed to perform on Linux with SELinux
(security-enhanced Linux) feature enabled, because its design
target is centralization of access control rules between DBMS
On Sunday, March 03, 2013 8:19 PM Craig Ringer wrote:
On 02/05/2013 11:53 PM, Amit Kapila wrote:
Performance data for the patch is attached with this mail.
Conclusions from the readings (these are same as my previous patch):
1. With orignal pgbench there is a max 7% WAL reduction with not
Maciek Sakrejda m.sakre...@gmail.com writes:
[ a bunch of questions that boil down to: ]
Isn't full fidelity possible assuming sensible rounding semantics and
enough characters of precision?
The fundamental issue is that the underlying representation is binary
and so its precision limit
On Mon, Mar 4, 2013 at 6:53 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 03/04/2013 01:42 AM, Alexander Korotkov wrote:
This patch only adds one more operator to already committed new
opclass. Tests already cover this case. Without patch corresponding
test leads to sequential scan
On Monday, March 04, 2013 7:26 AM Greg Smith wrote:
On 3/3/13 8:34 PM, Tom Lane wrote:
Neither of those names is consistent with any other PGDATA
subdirectory
name we use. It should just be config, or perhaps pg_config, though
the
latter risks confusion with the tool of the same name.
On Monday, March 04, 2013 9:41 AM Craig Ringer wrote:
On 03/04/2013 09:07 AM, Greg Smith wrote:
I'm not sure why you are opening the old auto config file with
ParseConfigFp. Can't you just navigate the existing GUCs in memory
and directly write the new one out? If someone is going to
Thanks for the reply, Craig
Fair enough so a little more background, perhaps. I have the core of this
program running (command line) successfully with libpq and mcrypt already
for some time. My goal now is to house the encrypted file data in a table
with all user processing done over the SSL
On 03/04/2013 01:02 PM, Kohei KaiGai wrote:
2013/3/4 Craig Ringer cr...@2ndquadrant.com:
- The SEPostgreSQL patches
I still need to test this on Windows:
SEPostgreSQL is designed to perform on Linux with SELinux
(security-enhanced Linux) feature enabled, because its design
target is
On 03/04/2013 01:51 PM, Cliff_Bytes wrote:
I hope this pseudo illustrates more of what I am doing to insert encrypted
data into a bytea column and then query the same column for decryption.
It does, but it doesn't let anyone compile it and actually reproduce the
problem you're encountering or
*That was a brilliant response! Thank you.*
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/LIBPQ-Implementation-Requiring-BYTEA-Data-tp5747243p5747263.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing
Hi,
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added this:
src/backend/rewrite/rewriteDefine.c.orig| 945 +...
...
create mode 100644 src/backend/rewrite/rewriteDefine.c.orig
Committers should be more careful if they want to do
On 4 March 2013 06:39, Boszormenyi Zoltan z...@cybertec.at wrote:
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added this:
src/backend/rewrite/rewriteDefine.c.orig| 945 +...
...
create mode 100644
On 1 March 2013 18:36, Josh Berkus j...@agliodbs.com wrote:
As I stepped up to work on the CF and then became immediately swamped in
other work I bear some of the responsibility for not keeping things
rolling.
Just FYI, this is exactly why I wanted a 2nd CF manager for this CF.
Where was
Hi,
Kevin already removed it with a followup commit:
http://git.postgresql.org/pg/commitdiff/d63977eea3ab18fdec05e370b633d10b9fd20179
Regards, Devrim
Boszormenyi Zoltan z...@cybertec.at wrote:
Hi,
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added
On 3 March 2013 18:24, Greg Smith g...@2ndquadrant.com wrote:
The 16-bit checksum feature seems functional, with two sources of overhead.
There's some CPU time burned to compute checksums when pages enter the
system. And there's extra overhead for WAL logging hint bits. I'll
quantify both
Committers,
please hold *all* pushes to the PostgreSQL repository until we have
resolved the issue mentioned in
http://www.postgresql.org/message-id/cabuevezm2f8qaxvds9me-41l5bqeego4duoscqhc0c6v05h...@mail.gmail.com.
Pushing anything at this point is likely to give us more work in
cleaning it
Hello
2013/3/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
here is patch
Applied, though without the regression test changes, because (a) that
didn't really seem necessary, and (b) I didn't feel like updating
xmlmap_1.out.
thank you for commit
in this use
On 03/04/2013 11:54 AM, Cliff_Bytes wrote:
I have a challenge on my hand as follows. I am a long time libpq user but
have never used the BYTEA data type nor its related functions until now. I
have am writing an interface for a web based application written in C using
libmcrypt and, of
86 matches
Mail list logo
