On Fri, Mar 29, 2013 at 7:22 PM, Andres Freund and...@2ndquadrant.comwrote:
- Index based regexp search for pg_trgm:
Seems like the patch is undergoing restructuring of the regex access API
= move to next fest
Last proposal of regex API by Tom seems simple enough in implementation for
Hi, Jey!
I remember I've started couple of threads related to cube extension:
http://www.postgresql.org/message-id/4f30616d.3030...@gmail.com
http://www.postgresql.org/message-id/4f3c16e9.90...@gmail.com
Could you provide some feedback to GSoC proposal of Stas?
On Sat, Mar 23, 2013 at 3:10 AM,
As we know, SSDs are widely used in various kinds of applications. But the
SMGR in PostgreSQL still only
support magnetic disk. How do we make full use of SSDs to improve the
performance of PostgreSQL?
--
Just do it!
On Sat, Mar 30, 2013 at 10:08:44PM +0800, 赖文豫 wrote:
As we know, SSDs are widely used in various kinds of applications. But the
SMGR
in PostgreSQL still only
support magnetic disk. How do we make full use of SSDs to improve the
performance of PostgreSQL?
When the storage manager (SMGR)
On Sat, Mar 30, 2013 at 3:55 PM, Alexander Korotkov aekorot...@gmail.comwrote:
Hi, Jey!
I remember I've started couple of threads related to cube extension:
Oh, it's a typo. I remember you've started those threads.
http://www.postgresql.org/message-id/4f30616d.3030...@gmail.com
Bruce Momjian br...@momjian.us writes:
On Sat, Mar 30, 2013 at 10:08:44PM +0800, èµæ豫 wrote:
As we know, SSDs are widely used in various kinds of applications. But the
SMGR
in PostgreSQL still only
support magnetic disk. How do we make full use of SSDs to improve the
performance of
On 03/30/2013 12:28 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sat, Mar 30, 2013 at 10:08:44PM +0800, 赖文豫 wrote:
As we know, SSDs are widely used in various kinds of applications. But the SMGR
in PostgreSQL still only
support magnetic disk. How do we make full use of
Andrew Dunstan and...@dunslane.net writes:
This isn't the first time I've seen this sort of comment. Do we need to
add some wording like the above to the top of md.c and the README in
that directory?
Yeah, probably. I'll go write something ...
regards, tom lane
--
On 2013-03-29 19:03:05 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit
clumsy.
That was what I started to write, too, but actually I think the IS
DISTINCT is correct and the RIGHT JOIN should be a LEFT
2013/03/30 23:31, Bruce Momjian wrote:
On Sat, Mar 30, 2013 at 10:08:44PM +0800, 赖文豫 wrote:
As we know, SSDs are widely used in various kinds of applications. But the SMGR
in PostgreSQL still only
support magnetic disk. How do we make full use of SSDs to improve the
performance of PostgreSQL?
Hi,
During the investigation of
http://archives.postgresql.org/message-id/CAL_0b1t%3DWuM6roO8dki%3Dw8DhH8P8whhohbPjReymmQUrOcNT2A%40mail.gmail.com
I noticed that during HS we do the following in
RecordKnownAssignedTransactionIds:
if (TransactionIdFollows(xid, latestObservedXid))
Jeff,
* Jeff Davis (pg...@j-davis.com) wrote:
On Thu, 2013-03-28 at 19:56 -0400, Stephen Frost wrote:
41K hashed, seqscan 4M: 115030.10 + 1229.46 = 116259.56
4M hashed, seqscan 41K: 1229.46 + 211156.20 = 212385.66
I think those are backwards -- typo?
Yes, sorry, those are backwards.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think the point is that there may *not* be few hash collisions ...
Right, but that's actually all entirely based on concerns over there
being duplicates (hence why we consider the MCVs and ndistinct), which
makes *some* sense given that we currently have
* Jeff Davis (pg...@j-davis.com) wrote:
In Stephen's case the table was only 41KB, so something still seems off.
Maybe we should model the likelihood of a collision based on the
cardinalities (assuming a reasonably good hash function)?
It's not really 'hash collisions' that we're trying to be
Simon, All,
The new approach seems fine to me; I haven't looked at the code. If Tom
doesn't feel like it's overly complicated, then this seems like a good
compromise.
The desire to move recovery.conf/trigger to a different directory is
definitely wanted by our Debian contingent. Right now, the
On 30 March 2013 18:20, Andres Freund and...@2ndquadrant.com wrote:
Simon, do you remember why you added that?
That doesn't look like code I added, but I'll look some more.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
Josh Berkus j...@agliodbs.com writes:
The desire to move recovery.conf/trigger to a different directory is
definitely wanted by our Debian contingent. Right now, the fact that
Debian has all .confs in /etc/, but that it doesn't work to relocate
recovery.conf, is a constant source of
On 30 March 2013 18:20, Andres Freund and...@2ndquadrant.com wrote:
Imo this shouldn't be needed.
In principle, I think your premise looks correct. ExtendCLOG() is not needed.
If the xid truly is known assigned at a point in time, then the clog
should already have been extended to allow that.
Simon Riggs si...@2ndquadrant.com writes:
On 30 March 2013 18:20, Andres Freund and...@2ndquadrant.com wrote:
Imo this shouldn't be needed.
In principle, I think your premise looks correct. ExtendCLOG() is not needed.
If the xid truly is known assigned at a point in time, then the clog
On 2013-03-30 18:24:44 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 30 March 2013 18:20, Andres Freund and...@2ndquadrant.com wrote:
Imo this shouldn't be needed.
In principle, I think your premise looks correct. ExtendCLOG() is not
needed.
If the xid truly
On 2013-03-30 23:58:26 +0100, Andres Freund wrote:
I am pretty sure that the scenario you describe happens for SUBTRANS
tho. Leading to the reported bug.
For a slightly too long explanation see:
http://archives.postgresql.org/message-id/20130330172144.GI28736%40alap2.anarazel.de
Greetings,
On Mar 30, 2013 7:13 PM, Satoshi Nagayasu sn...@uptime.jp wrote:
But I heard that larger block size, like 256kB, would take
advantage of the SSD performance because of the block management
within SSD.
This is only true for very bad SSDs. Any SSD that you would want to trust
with your data do
OK, patch applied and backpatched as far back as pg_upgrade exists in
git.
---
On Fri, Mar 29, 2013 at 11:35:13PM -0400, Bruce Momjian wrote:
On Fri, Mar 29, 2013 at 07:03:05PM -0400, Tom Lane wrote:
Andres Freund
On Wed, 2013-03-27 at 17:06 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 3/24/13 1:55 PM, Tom Lane wrote:
I experimented a bit with this version of the patch. The hunk that
removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build
breaks the build for me,
On Mar 20, 2013, at 1:45 AM, David E. Wheeler da...@kineticode.com wrote:
Is there currently any way to create an index that can be used to speed up
searches like the one above?
If not, do you have any idea how it might be implemented? Perhaps I could
give it a try myself.
Thank you in
David E. Wheeler da...@kineticode.com writes:
Hackers, what would be required to get an index on a CITEXT column to support
LIKE?
The LIKE index optimization is hard-wired into
match_special_index_operator(), which never heard of citext's ~~
operators.
I've wanted for years to replace that
26 matches
Mail list logo
