On Fri, Mar 29, 2013 at 7:22 PM, Andres Freund wrote:
> - 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
me. I'm going to po
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, St
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 wrote:
> 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
> http://www.postgresql.o
Bruce Momjian 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 PostgreS
On 03/30/2013 12:28 PM, Tom Lane wrote:
Bruce Momjian 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 t
Andrew Dunstan 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
--
Sent via pgsql-
On 2013-03-29 19:03:05 -0400, Tom Lane wrote:
> Andres Freund 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 JOIN. Note
>
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 backw
* 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 b
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 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
--
Sent via pgsql-
Josh Berkus 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 irritation.
It seems l
On 30 March 2013 18:20, Andres Freund 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.
I can't recall any
Simon Riggs writes:
> On 30 March 2013 18:20, Andres Freund 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 all
On 2013-03-30 18:24:44 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On 30 March 2013 18:20, Andres Freund 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
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,
A
On Mar 30, 2013 7:13 PM, "Satoshi Nagayasu" 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 block remapp
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 wri
On Wed, 2013-03-27 at 17:06 -0400, Tom Lane wrote:
> Peter Eisentraut 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, so
On Mar 20, 2013, at 1:45 AM, David E. Wheeler 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 advance fo
"David E. Wheeler" 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 mechanism with some
26 matches
Mail list logo
