On 2 March 2013 15:06, Kevin Grittner 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 the only one I
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 (+indi
Dean Rasheed wrote:
> Kevin Grittner 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 the onl
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 hav
On 03/02/2013 12:48 AM, Daniel Farina wrote:
> On Sun, Feb 24, 2013 at 10:30 PM, Greg Smith 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 has hit zero, I'
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 wor
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 reco
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 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 looking for 9.3? O
On 3 March 2013 13:12, Kevin Grittner wrote:
> Dean Rasheed wrote:
>> Kevin Grittner 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
On Sun, Mar 3, 2013 at 6:53 PM, Craig Ringer 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, _most_ recent acitivi
On Sun, Mar 3, 2013 at 6:37 PM, Craig Ringer 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 more detail? Wo
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 quickly
Kevin Grittner 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 wrd
> T
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:
http://www.po
> 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 (pgsql-
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 exa
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.
>
2013/3/3 Kevin Grittner :
> 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 unlikely to
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 2
Nicolas Barbier wrote:
> 2013/3/3 Kevin Grittner :
>> 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,
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 pa
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.
Wh
Satoshi Nagayasu 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 arguments
On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner 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 direction of flo
2013/3/3 Kevin Grittner :
> Nicolas Barbier 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, queries can be written the natural
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 scr
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 blew
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
int
> 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, becaus
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 modificatio
Nicolas Barbier writes:
> 2013/3/3 Kevin Grittner :
>> Nicolas Barbier 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.
>> Oh, I understa
Andres Freund writes:
> On 2013-02-14 20:47:11 -0500, Tom Lane wrote:
>> Andres Freund 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 RelisBecomingView case.
>> Yeah, pro
> 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 w
Pavel Stehule 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 (pgsql-hackers@postgresq
Kevin Grittner 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 patch
> to al
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 aro
> 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 writ
Josh Berkus 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 here, and n
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 is
> 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 implicati
On 03/03/2013 11:17 PM, Tom Lane wrote:
> Craig Ringer 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 prev
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 a
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
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.
The
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 bou
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:
http://www.
-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 lock
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
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 par
* 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
-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,
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, perf
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 cours
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 so
On 03/04/2013 09:34 AM, Tom Lane wrote:
> Josh Berkus 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
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 fro
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 patc
2013/3/4 Craig Ringer :
> - 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
and operating system
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 reduct
Maciek Sakrejda 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 doesn't correspond to an
On Mon, Mar 4, 2013 at 6:53 AM, Craig Ringer 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 instead of inde
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
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 t
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 int
On 03/04/2013 01:02 PM, Kohei KaiGai wrote:
> 2013/3/4 Craig Ringer :
>> - 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 o
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 t
*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 list
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 wo
On 4 March 2013 06:39, Boszormenyi Zoltan wrote:
> 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
On 1 March 2013 18:36, Josh Berkus 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 that discus
Hi,
Kevin already removed it with a followup commit:
http://git.postgresql.org/pg/commitdiff/d63977eea3ab18fdec05e370b633d10b9fd20179
Regards, Devrim
Boszormenyi Zoltan wrote:
>Hi,
>
>commit 3bf3ab8c563699138be02f9dc305b7b77a724307
>("Add a materialized view relations.") added this:
>
> src/b
On 3 March 2013 18:24, Greg Smith 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 of those better in
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 up,
Hello
2013/3/4 Tom Lane :
> Pavel Stehule 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 case I am think so some regression te
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 cou
86 matches
Mail list logo
