Hi.
Ok, ok thanks.
My problem is to shorten time of searching full text stored in text field.
The table definition is like following:
CREATE TABLE xxx
(
...
title character varying,
...
fts1body text,
...
)
If user requests keywords, we use a kind of stristr that is targeting
On 08.07.2013 00:48, Markus Wanner wrote:
On 07/07/2013 09:51 PM, Dimitri Fontaine wrote:
The design we found to address that is
called Extension Templates and is implemented in the current patch.
I placed my concerns with the proposed implementation. It's certainly
not the only way how
On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
On 08.07.2013 00:48, Markus Wanner wrote:
On 07/07/2013 09:51 PM, Dimitri Fontaine wrote:
The design we found to address that is
called Extension Templates and is implemented in the current patch.
I placed my concerns with the proposed
On 01.07.2013 16:40, Andres Freund wrote:
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
* Could you document the way slots prevent checkpoints from occurring
when XLogInsert rechecks for full page writes? I think it's correct -
but not very obvious on a glance.
There's this in
Hello,
- How about pageinspect?
I proposed a simple representation format as a basis for
discussion. Nevertheless, the VM pages has no more structure
than a simple bit string. Given the VM info in pg_freespacemap,
I've come in doubt of the necessity of vm_page_contnets() for
On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
I'm just now dabbling back to this thread after skipping a lot of
discussion, and I'm disappointed to see that this still seems to be
running in circles on the same basic question: What exactly is the
patch trying to accomplish.
Bypassing the
Peter Eisentraut pete...@gmx.net writes:
local_preload_libraries allows unprivileged users to preload whitelisted
libraries. session_preload_libraries allows superusers to preload any
library. It's hard to see how to consolidate those, at least without
adding another setting that whitelists
I create fsync v2 patch. There's not much time, so I try to focus fsync patch in
this commit festa as adviced by Heikki. And I'm sorry that it is not good that
diverging from main discussion in this commit festa... Of course, I continue to
try another improvement.
* Changes
- Add ckpt_flag
On 06/10/2013 09:43 PM, Hannu Krosing wrote:
On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
The concept was useful, but not something we want
to call an extension, because the distinguishing feature of an
extension is that it lives outside the database and is *not* included
in pg_dump.
Jaime Casanova ja...@2ndquadrant.com writes:
the name). I'm talking about get_ext_ver_list_from_catalog() which is
a different
function.
Oh. I see it now. Sorry about that. It's blindly fixed in my git repo
and I'm going to send an updated patch soon now™ which will include the
fix.
Thanks
2013/7/8 Hadi Moshayedi h...@moshayedi.net:
I am attaching the updated the patch, which also fixes a bug which
caused one of the regression tests failed.
I'll subscribe this patch to the commitfest in the next hour.
Can you please review the patch?
sure, :)
Pavel
Thanks,
-- Hadi
Ok, I've committed this patch now. Finally, phew!
I think I've addressed all your comments about the comments. I moved
some of the comments around: I split up the large one near the top of
the file, moving its paragraphs closer to the code where they apply.
Regarding your performance-related
On 08.07.2013 12:16, Heikki Linnakangas wrote:
I just remembered one detail that I'm not sure has been mentioned on the
mailing list yet. Per the commit message:
This has one user-visible change: switching to a new WAL segment with
pg_switch_xlog() now fills the remaining unused portion of the
On 27.06.2013 20:36, Andres Freund wrote:
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
There's this in the comment near the top of the file:
Btw, I find the 'you' used in the comment somewhat irritating. Not badly
so, but reading something like:
* When you are about to write
*
On 07/08/2013 10:20 AM, Dimitri Fontaine wrote:
Bypassing the file system entirely in order to install an extension. As
soon as I figure out how to, including C-coded extensions.
Do I understand correctly that you want to keep the extensions (or their
templates) out of the dump and require the
Hi,
Please find attached to this mail version 9 of the Extension Templates
patch with fixes for the review up to now.
Markus Wanner mar...@bluegap.ch writes:
I still think that we shouldn't allow creating a template for an
extension that is already installed, though. Do you have any
what is log switch and when it occur ?
On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
Fantastic work!
I simplified the handling of xlogInsertingAt per discussion, and added the
memory barrier to GetXLogBuffer(). I ran again the pgbench tests I
On Wednesday, July 03, 2013 1:21 PM Kyotaro HORIGUCHI wrote:
Hello,
I could see the same output with your latest script, also I could
reproduce
the test if I run the test with individual sql statements.
One of the main point for reproducing individual test was to keep
autovacuum
=
On 08.07.2013 13:21, Ants Aasma wrote:
On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
Fantastic work!
I simplified the handling of xlogInsertingAt per discussion, and added the
memory barrier to
On 2013-07-08 10:45:41 +0300, Heikki Linnakangas wrote:
On 01.07.2013 16:40, Andres Freund wrote:
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
* Could you document the way slots prevent checkpoints from occurring
when XLogInsert rechecks for full page writes? I think it's correct
On Friday, July 05, 2013 6:48 PM Hari Babu wrote:
On Thursday, July 04, 2013 11:19 PM Robert Haas wrote:
The patch is updated with the following changes.
1.If the input data is data directory, all the errors occurred are displayed
at once instead of one error at a time.
2.Fixed the problem of
On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
+This utility can also be used to decide whether backup is required or
not when the data page
+in old-master precedes the last applied LSN in old-standby (i.e.,
new-master) at the
+moment of the failover.
+ /para
+ /refsect1
I
Hello,
I've found a bug in PostgreSQL 9.3 beta 2 which is related to statistics
collection which emits excesssive amount of error messages. Please find
attached the patch to fix this. I confirmed this problem occurs in
PostgreSQL 9.2, too. Could you backport this?
[Problem]
If the
On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
+This utility can also be used to decide whether backup is
required or not when the data page
+in old-master precedes the last applied LSN in old-standby
(i.e., new-master) at the
On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
+This utility can also be used to decide whether backup is
required or not when the data page
+in old-master precedes the last
On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
+This utility can also be used to decide whether backup is
required or not when
Recently i got annoyed that psql doesn't tab complete to updatable foreign
tables.
Attached is a patch to address this. I'm using the new
pg_relation_is_updatable() function to accomplish this. The function could
also be used for the trigger based stuff in the query, but i haven't
touched
On Mon, Jul 8, 2013 at 1:38 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
GetXLogBuffer() doesn't read the content of the page - it writes to it (or
rather, the caller of GetXLogBarrier() does). The barrier is needed between
reading xlblocks (to check that the buffer contains the right
MauMau maumau...@gmail.com writes:
I've found a bug in PostgreSQL 9.3 beta 2 which is related to statistics
collection which emits excesssive amount of error messages. Please find
attached the patch to fix this. I confirmed this problem occurs in
PostgreSQL 9.2, too. Could you backport
On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
+This utility can also be used to decide whether backup is
required or not
Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
On Fri, Feb 08, 2013 at 02:51:40PM +0100, Kohei KaiGai wrote:
I'll have a discussion about new materialized_view object class
on selinux list soon, then I'll submit a patch towards
contrib/sepgsql according to the
On 8 July 2013 12:46, Bernd Helmle maili...@oopsware.de wrote:
Recently i got annoyed that psql doesn't tab complete to updatable foreign
tables.
Attached is a patch to address this. I'm using the new
pg_relation_is_updatable() function to accomplish this. The function could
also be used for
On 5 July 2013 23:47, ivan babrou ibob...@gmail.com wrote:
On 5 July 2013 23:26, Tom Lane t...@sss.pgh.pa.us wrote:
ivan babrou ibob...@gmail.com writes:
If you can figure out that postgresql is overloaded then you may
decide what to do faster. In our app we have very strict limit for
connect
On Jul 8, 2013, at 7:44 AM, ivan babrou ibob...@gmail.com wrote:
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
Nobody answered my question yet.
From an earlier post by Tom:
What exactly is the use case for that? It seems like extra
All,
Normally the CommitFest would be ending in one week. Our current status
for the commitfest is:
Needs Review: 24
Waiting on Author: 17,
Ready for Committer: 13,
Committed: 35,
Returned with Feedback: 18,
Rejected: 2.
At current rates, CF1 will not conclude for four weeks.
Of the patches
On 06/23/2013 09:43 PM, Abhijit Menon-Sen wrote:
(Cc: to pgsql-performance dropped, pgsql-hackers added.)
At 2013-05-06 09:14:01 +0100, si...@2ndquadrant.com wrote:
New version of patch attached which fixes a few bugs.
I read the patch, but only skimmed the earlier discussion about it. In
Le lundi 8 juillet 2013 18:40:29, David E. Wheeler a écrit :
On Jul 8, 2013, at 7:44 AM, ivan babrou ibob...@gmail.com wrote:
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
Nobody answered my question yet.
From an earlier post by Tom:
What
On 07/07/2013 09:14 PM, Hadi Moshayedi wrote:
I am attaching the updated the patch, which also fixes a bug which
caused one of the regression tests failed.
I'll subscribe this patch to the commitfest in the next hour.
Can you please review the patch?
I'm afraid that, since this patch
On Fri, 2013-07-05 at 22:43 -0700, Jeff Davis wrote:
On Sat, 2013-07-06 at 10:30 +0900, Satoshi Nagayasu wrote:
Hi,
It looks fine, but I have one question here.
When I run pg_filedump with -k against a database cluster which
does not support checksums, pg_filedump produced checksum
Hello
2013/7/8 Josh Berkus j...@agliodbs.com:
On 07/07/2013 09:14 PM, Hadi Moshayedi wrote:
I am attaching the updated the patch, which also fixes a bug which
caused one of the regression tests failed.
I'll subscribe this patch to the commitfest in the next hour.
Can you please review the
On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis pg...@j-davis.com wrote:
I see this patch is still waiting on author in the CF. Is there
something else needed from me, or should we move this to ready for
committer?
Well, obviously someone still needs to think through the handling of
the infoMask
Pavel,
sure, it should be in September CF. It is relative simple patch
without global impacts. But I like it, it increase speed for
sum(numeric) about 25% and avg(numeric) about 50%
Do you think you could give this a review after CF1 ends, but before
September? I hate to make Hadi wait
2013/7/8 Josh Berkus j...@agliodbs.com:
Pavel,
sure, it should be in September CF. It is relative simple patch
without global impacts. But I like it, it increase speed for
sum(numeric) about 25% and avg(numeric) about 50%
Do you think you could give this a review after CF1 ends, but before
On 07/03/2013 11:59 AM, Robert Haas wrote:
Yeah. I think the system columns that we have today are pretty much
crap. I wonder if we couldn't throw them out and replace them with
some kind of functions that you can pass a row to. That would allow
us to expose a lot more detail without adding
On 06/26/2013 07:05 AM, Jamie Martin wrote:
FYI I submitted a slightly modified patch since Amit's measurements that is
slightly faster.
Yes. My perspective is that this is a worthwhile optimization for a
minority, but fairly well-known, use case, provided that it doesn't
negatively impact
On 07/03/2013 11:28 AM, Peter Eisentraut wrote:
On 6/6/13 4:09 PM, Heikki Linnakangas wrote:
I don't understand what this patch, by itself, will accomplish in terms
of the originally stated goals of making checkpoint_segments easier to
tune, and controlling disk space used. To some degree, it
On 07/08/2013 12:59 AM, Kyotaro HORIGUCHI wrote:
I'll come again with the first implementation of it. And as for
pg_freespacemap, I'll keep the current direction - adding column
to present output records format of pg_freespace(). And
documentation, if possible.
Do you think you'll be fixing
On 06/29/2013 04:11 PM, Greg Smith wrote:
I need to catch up with revisions done to this feature since I started
instrumenting my copy more heavily. I hope I can get this ready for
commit by Monday. I've certainly beaten on the feature for long enough
now.
Greg, any progress? Haven't seen
Peter Geoghegan escribió:
On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis pg...@j-davis.com wrote:
I see this patch is still waiting on author in the CF. Is there
something else needed from me, or should we move this to ready for
committer?
Well, obviously someone still needs to think
With the current HEAD and v3 patch I'm seeing the following error with
make check.
--
== creating temporary installation==
== initializing database system ==
pg_regress: initdb failed
Examine
Peter,
On 07/07/2013 12:06 PM, Peter Eisentraut wrote:
Good point. My original patch allowed func(sql_type) - internal, but I
took that out because people had security concerns.
I'd be OK with restricting transform creation to superusers in the first
cut.
Have we added the ability of
On Mon, Jul 8, 2013 at 11:52 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Well, Tom opined in
http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that
the current patch is okay. I have a mild opinion that it should instead
print only SHR_LOCK when both bits are set, and
On 07/05/2013 10:09 PM, Michael Paquier wrote:
Yeah, it would be good to revive this thread now, which is the
beginning of the development cycle. As of now, just to recall
everybody, an agreement on this patch still needs to be found... Simon
is concerned with backward compatibility. Greg
On 06/24/2013 06:55 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
What about simply not using a keyword at that location at all? Something
like the attached hack?
Generally speaking, I agree with Robert's objection. The patch in
itself adds only one unnecessary keyword,
On 07/03/2013 12:51 AM, Kyotaro HORIGUCHI wrote:
It is tough to decide how to modify there. Currently I decided to
preserve vac_estimate_reltuples as possible as it is. For that
objective, I picked up old_rel_tuples as intermediate variable
for the aid to 'deceive' the function. This can be
Hello Dimitri,
On 07/08/2013 11:49 AM, Dimitri Fontaine wrote:
Please find attached to this mail version 9 of the Extension Templates
patch with fixes for the review up to now.
Thanks, cool.
Markus Wanner mar...@bluegap.ch writes:
I still think that we shouldn't allow creating a template
On 8 July 2013 20:40, David E. Wheeler da...@justatheory.com wrote:
On Jul 8, 2013, at 7:44 AM, ivan babrou ibob...@gmail.com wrote:
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
Nobody answered my question yet.
From an earlier post by Tom:
On 07/04/2013 06:18 AM, Andrew Dunstan wrote:
On 07/04/2013 09:14 AM, Cédric Villemain wrote:
ah yes, good catch, I though .control file were unique per contrib,
but there aren't.
It's already been fixed.
Does it look like this patch will get into committable shape in the next
couple of
On 07/08/2013 03:40 PM, Josh Berkus wrote:
On 07/04/2013 06:18 AM, Andrew Dunstan wrote:
On 07/04/2013 09:14 AM, Cédric Villemain wrote:
ah yes, good catch, I though .control file were unique per contrib,
but there aren't.
It's already been fixed.
Does it look like this patch will get
I think everything has been committed - as I think the CF app shows. The
only thing left in this srea from Cédric is the insallation of headers,
which Peter is down to review and is in Waiting on Author status.
Yeah, that's the one I'm asking about. is that going to get done in the
next few
On Mon, Jul 08, 2013 at 03:21:09PM +0900, kenji uno wrote:
Hi.
Ok, ok thanks.
My problem is to shorten time of searching full text stored in text field.
Ok, your explanation of your problem really helps, thanks.
However the following query is very slow! 9,400ms. It uses Seq Scan lol.
Hello
updated patch
+ more precious validity check
Regards
Pavel
2013/7/3 Pavel Stehule pavel.steh...@gmail.com:
Hello
So my vote is for make_time(hour int, min int, sec float8).
so here is a patch
Regards
Pavel
regards, tom lane
make_date-v2.patch
On Jul 8, 2013, at 4:16 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
Woohoo!
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jul 8, 2013, at 1:34 PM, Josh Berkus j...@agliodbs.com wrote:
On 07/03/2013 11:59 AM, Robert Haas wrote:
Yeah. I think the system columns that we have today are pretty much
crap. I wonder if we couldn't throw them out and replace them with
some kind of functions that you can pass a row
On 2013/07/09, at 4:09, Josh Berkus j...@agliodbs.com wrote:
On 07/05/2013 10:09 PM, Michael Paquier wrote:
Yeah, it would be good to revive this thread now, which is the
beginning of the development cycle. As of now, just to recall
everybody, an agreement on this patch still needs to be
For 9.3 and 9.4, all the interesting stuff was moved from htup.h to
htup_details.h (c219d9b0a55bcdf81b00da6b) , but the docs for the
pageinspect extension were not updated correspondingly.
Attached patch to change the docs.
Cheers,
Jeff
pageinspect_doc_v1.patch
Description: Binary data
--
Jeff Janes escribió:
For 9.3 and 9.4, all the interesting stuff was moved from htup.h to
htup_details.h (c219d9b0a55bcdf81b00da6b) , but the docs for the
pageinspect extension were not updated correspondingly.
Attached patch to change the docs.
Applied, thanks.
--
Álvaro Herrera
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com writes:
If the directory specified by stats_temp_directory becomes inaccessible
to
postgres, enormous amount of WARNING messages are output.
Well, yeah, because all of that functionality just broke. Not warning
about it doesn't
I can't comment on further direction for the patch, but since it was marked
as Needs Review in the CF app I took a quick look at it.
It patches and compiles clean against the current Git HEAD, and 'make
check' runs successfully.
Does it need documentation for the GUC variable
On 07/08/2013 02:21 PM, Mike Blackwell wrote:
I can't comment on further direction for the patch, but since it was marked
as Needs Review in the CF app I took a quick look at it.
It patches and compiles clean against the current Git HEAD, and 'make
check' runs successfully.
Does it need
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
+1. Great patch!
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Well, Tom opined in
http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that
the current patch is okay. I have a mild opinion that it should instead
print only SHR_LOCK when both bits are set, and one of the others when
only one
Reviewer, Testers:
As part of an ongoing effort to encourage patch review for the
PostgreSQL project, we will be funding cloud servers for patch reviewers
and testers who need them for CommitFests. That is, if you want to help
with reviewing or testing a patch for a CommitFest, and don't have
When rebasing a patch that I'm working on, I occasionally forget to
update the oid of any pg_proc.h entries I may have created. Of course
this isn't a real problem; when I go to initdb, I immediately
recognize what has happened. All the same, it seems like there is a
case to be made for having
Hey,
New patch attached. I've moved from using a boolean to an enum trivalue.
Let me know what you think.
Cheers,
James
James Sewell
PostgreSQL Team Lead / Solutions Architect
_
[image:
http://www.lisasoft.com/sites/lisasoft/files/u1/2013hieghtslogan_0.png]
Peter Geoghegan p...@heroku.com writes:
... All the same, it seems like there is a
case to be made for having this run automatically at build time, and
having the build fail on the basis of there being a duplicate
This would require a rather higher standard of portability than
duplicate_oids
On 07/09/2013 08:35 AM, Josh Berkus wrote:
Since these are cloud servers, they won't work well for performance
testing.
I did some work on that a while ago, and found that I was able to get
_astonishingly_ stable performance results out of EC2 EBS instances
using provisioned IOPS volumes.
On Mon, Jul 8, 2013 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would require a rather higher standard of portability than
duplicate_oids has heretofore been held to.
Ah, yes. I suppose that making this happen would necessitate rewriting
the script in highly portable Perl.
On Jul 8, 2013, at 1:31 PM, ivan babrou ibob...@gmail.com wrote:
On 8 July 2013 20:40, David E. Wheeler da...@justatheory.com wrote:
On Jul 8, 2013, at 7:44 AM, ivan babrou ibob...@gmail.com wrote:
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
On Mon, 2013-07-08 at 19:38 -0700, Peter Geoghegan wrote:
On Mon, Jul 8, 2013 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would require a rather higher standard of portability than
duplicate_oids has heretofore been held to.
Ah, yes. I suppose that making this happen would
On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut pete...@gmx.net wrote:
I don't think rewriting it in Perl is necessary or even desirable. I
don't see anything particularly unportable in that script as it is.
I was under the impression that the final patch ought to work on
Windows too.
On Tuesday, July 09, 2013 2:52 AM Mike Blackwell wrote:
I can't comment on further direction for the patch, but since it was marked
as Needs Review in the CF app I took a quick look at it.
Thanks for looking into it.
Last time Heikki has found test scenario's where the original patch was
On 07/09/2013 11:03 AM, Peter Geoghegan wrote:
On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut pete...@gmx.net wrote:
I don't think rewriting it in Perl is necessary or even desirable. I
don't see anything particularly unportable in that script as it is.
I was under the impression that the
On Tue, Jul 9, 2013 at 6:55 AM, Peter Geoghegan p...@heroku.com wrote:
When rebasing a patch that I'm working on, I occasionally forget to
update the oid of any pg_proc.h entries I may have created. Of course
this isn't a real problem; when I go to initdb, I immediately
recognize what has
On Mon, Jul 8, 2013 at 7:25 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 07/09/2013 08:35 AM, Josh Berkus wrote:
Since these are cloud servers, they won't work well for performance
testing.
I did some work on that a while ago, and found that I was able to get
_astonishingly_ stable
86 matches
Mail list logo
