On Wed, May 25, 2016 at 09:10:02AM +, Kouhei Kaigai wrote:
> > -Original Message-
> > From: Simon Riggs [mailto:si...@2ndquadrant.com]
> > Sent: Wednesday, May 25, 2016 4:39 PM
> > To: Kaigai Kouhei(海外 浩平)
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Does people favor
On Wed, Sep 23, 2015 at 04:33:33PM -0700, Josh Berkus wrote:
> On 09/23/2015 03:05 PM, Jim Nasby wrote:
> > On 9/23/15 3:12 PM, Thomas Kellerer wrote:
> >> They also support Postgres as their backend (and you do find hints
> >> here and
> >> there
> >> that it is the recommended open source DBMS fo
On Wed, Sep 16, 2015 at 03:57:04PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer wrote:
> >> Our implementation of << is a direct wrapper around the C operator. It
> >> does not check the right-hand side's value.
> >> ... On x64 intel gcc linux it
On Fri, Jun 05, 2015 at 11:54:01PM +, deavid wrote:
> Thanks to everybody for answering. I wasn't expecting this attention; this
> is a great community :-)
>
> Jim asked me about something real. Well, the problem is this showed up more
> than five years ago, and keeps popping from time to time
On Mon, Apr 06, 2015 at 12:07:47PM -0500, Jim Nasby wrote:
> ...
> As I understand it, the goal here is to prevent huge amounts of
> periodic freeze work due to XID wraparound. I don't think we need
> the Freeze state to accomplish that.
>
> With a single bit per page in the Frozen Map, checking a
On Mon, Mar 23, 2015 at 09:41:40PM +, Andrew Gierth wrote:
> > "Peter" == Peter Geoghegan writes:
>
> Peter> As I said, I don't really consider that my patch is a rewrite,
> Peter> especially V4, which changes nothing substantive except removing
> Peter> 32-bit support.
>
> Well, that
On Thu, Feb 26, 2015 at 10:59:50PM +0100, Grzegorz Parka wrote:
> Dear Hackers,
>
> I'm Grzegorz Parka, BSc Engineer of Technical Physics and student of
> Computer Science at WUT, Poland. Last year I've been a bit into
> evolutionary algorithms and during my research I found out about GEQO in
> Po
On Fri, Jan 02, 2015 at 01:01:06PM +0100, Andres Freund wrote:
> On 2014-12-31 16:09:31 -0500, Bruce Momjian wrote:
> > I still don't understand the value of adding WAL compression, given the
> > high CPU usage and minimal performance improvement. The only big
> > advantage is WAL storage, but aga
On Fri, Dec 19, 2014 at 04:41:51PM -0600, Jim Nasby wrote:
> On 12/18/14, 5:00 PM, Jim Nasby wrote:
> >2201582 20 -- Mostly LOCALLOCK and Shared Buffer
>
> Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
> be worth looking at, though it requires uint64.
>
> It also
On Wed, Dec 03, 2014 at 02:08:27PM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Do you need to plan for every combination, where some joins are removed
> > and some are not?
>
> I would vote for just having two plans and one switch node. To exploit
> any finer grain, we'd have to hav
On Wed, Dec 03, 2014 at 10:00:26AM -0300, Alvaro Herrera wrote:
> Amit Langote wrote:
>
> > From: Robert Haas [mailto:robertmh...@gmail.com]
>
> > > What is an overflow partition and why do we want that?
> >
> > That would be a default partition. That is, where the tuples that
> > don't belong e
On Fri, Nov 21, 2014 at 03:41:45PM +0530, Abhijit Menon-Sen wrote:
> At 2014-11-20 13:47:00 +0530, a...@2ndquadrant.com wrote:
> >
> > > Suggestions for how to address (b) are welcome.
>
> With help from Andres, I set up a workload where XLogInsert* was at the
> top of my profiles: server with fsy
On Tue, Nov 04, 2014 at 11:44:22AM +0900, Michael Paquier wrote:
> On Sun, Nov 2, 2014 at 2:30 AM, Tom Lane wrote:
>
> > In the case of hash indexes, because we still have to have the hash
> > opclasses in core, there's no way that it could be pushed out as an
> > extension module even if we othe
On Tue, Oct 28, 2014 at 01:51:21PM -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On 28 October 2014 17:06, Tom Lane wrote:
> >> My own thought is that allowing external AMs is simply a natural
> >> consequence of PG's general approach to extensibility, and it would
> >> be surprising if we wer
On Mon, Oct 20, 2014 at 09:03:59PM +0200, jes...@krogh.cc wrote:
> Hi.
>
> One of our "production issues" is that the system generates lots of
> wal-files, lots is like 151952 files over the last 24h, which is about
> 2.4TB worth of WAL files. I wouldn't say that isn't an issue by itself,
> but th
On Sun, Sep 14, 2014 at 05:21:10PM +0200, Andres Freund wrote:
> On 2014-09-13 20:27:51 -0500, k...@rice.edu wrote:
>
> > Also, while I understand that CRC has a very venerable history and
> > is well studied for transmission type errors, I have been unable to find
>
On Sat, Sep 13, 2014 at 09:50:55PM -0300, Arthur Silva wrote:
> On Sat, Sep 13, 2014 at 1:55 PM, Tom Lane wrote:
>
> > Andres Freund writes:
> > > On 2014-09-13 08:52:33 +0300, Ants Aasma wrote:
> > >> On Sat, Sep 13, 2014 at 6:59 AM, Arthur Silva
> > wrote:
> > >>> That's not entirely true. CR
On Sat, Sep 13, 2014 at 12:55:33PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-09-13 08:52:33 +0300, Ants Aasma wrote:
> >> On Sat, Sep 13, 2014 at 6:59 AM, Arthur Silva wrote:
> >>> That's not entirely true. CRC-32C beats pretty much everything with the
> >>> same
> >>> length qu
On Fri, Sep 12, 2014 at 11:17:12PM +0300, Ants Aasma wrote:
> On Fri, Sep 12, 2014 at 10:38 PM, Heikki Linnakangas
> wrote:
> > I don't mean that we should abandon this patch - compression makes the WAL
> > smaller which has all kinds of other benefits, even if it makes the raw TPS
> > throughput
On Thu, Sep 11, 2014 at 02:54:36PM -0300, Arthur Silva wrote:
> Indeed I don't know any other architectures that this would be at an
> option. So if this ever moves forward it must be turned on at compile time
> for x86-64 only. I wonder how the Mysql handle their rows even on those
> architectures
On Thu, Sep 11, 2014 at 07:17:42PM +0200, Andres Freund wrote:
> On 2014-09-11 13:04:43 -0400, Robert Haas wrote:
> > On Thu, Sep 11, 2014 at 12:58 PM, Andres Freund
> > wrote:
> > > On 2014-09-11 12:55:21 -0400, Robert Haas wrote:
> > >> I advise supporting pglz only for the initial patch, and a
On Thu, Sep 11, 2014 at 06:58:06PM +0200, Andres Freund wrote:
> On 2014-09-11 12:55:21 -0400, Robert Haas wrote:
> > I advise supporting pglz only for the initial patch, and adding
> > support for the others later if it seems worthwhile. The approach
> > seems to work well enough with pglz that i
On Thu, Sep 11, 2014 at 09:37:07AM -0300, Arthur Silva wrote:
> I agree that there's no reason to fix an algorithm to it, unless maybe it's
> pglz. There's some initial talk about implementing pluggable compression
> algorithms for TOAST and I guess the same must be taken into consideration
> for t
On Tue, Sep 02, 2014 at 10:30:11AM -0300, Arthur Silva wrote:
> On Tue, Sep 2, 2014 at 9:11 AM, Rahila Syed wrote:
>
> > Hello,
> >
> > >It'd be interesting to check avg cpu usage as well
> >
> > I have collected average CPU utilization numbers by collecting sar output
> > at interval of 10 secon
On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
> On Thu, Aug 28, 2014 at 11:26:53AM -0700, Kevin Grittner wrote:
> > Steve Crawford wrote:
> >
> > > I have always considered "timestamp with time zone" to be a bad
> > > description of that data type but it appears to be a carryover
On Wed, Apr 30, 2014 at 12:26:20AM -0700, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas wrote:
> >> As a GSoC student, I will implement WAL recovery of hash indexes using the
> >> other index types' WAL code as a guide.
>
> Frankly, I'm skeptical of the idea that hash index
On Thu, Apr 10, 2014 at 09:13:47PM +0800, Olivier Lalonde wrote:
> I was wondering if there would be any way to do the following in PostgreSQL:
>
> UPDATE cryptotable SET work = work + 'some big hexadecimal number'
>
> where work is an unsigned 256 bit integer. Right now my column is a
> char
On Thu, Mar 06, 2014 at 06:14:21PM -0500, Robert Haas wrote:
> On Thu, Mar 6, 2014 at 3:44 PM, Jeff Janes wrote:
> >
> > I've been tempted to implement a new type of hash index that allows both WAL
> > and high concurrency, simply by disallowing bucket splits. At the index
> > creation time you u
On Thu, Feb 06, 2014 at 04:21:41PM +0100, Rafael Martinez Guerrero wrote:
> On Thu, 2014-02-06 at 07:11 -0800, Adrian Klaver wrote:
> > On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote:
>
> > > We think the behavior should be consistent, either it is allow to use
> > > them or not, but not l
On Mon, Dec 09, 2013 at 11:40:41PM +0400, knizhnik wrote:
> Hello!
>
> I want to annouce my implementation of In-Memory Columnar Store
> extension for PostgreSQL:
>
> Documentation: http://www.garret.ru/imcs/user_guide.html
> Sources: http://www.garret.ru/imcs-1.01.tar.gz
>
> Any feedb
On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote:
>
> I believe this was a danger we recognized when we added the JSON type,
> including the possibility that a future binary type might need to be a
> separate type due to compatibility issues. The only sad thing is the
> naming; it woul
On Fri, Nov 01, 2013 at 01:31:10PM +, Dimitri Fontaine wrote:
> Hi,
>
> Here's an idea: when a user ask for an Hash Index transparently build a
> BTree index over an hash function instead.
>
> Advantages:
>
> - it works
> - it's crash safe
> - it's (much?) faster than a hash index anyw
On Tue, Oct 29, 2013 at 02:53:37PM +, Leonardo Francalanci wrote:
> > Before getting too excited about some new academic index type, it's worth
> > noting the sad state in which hash indexes have languished for years.
> > Nobody's bothered to add WAL support, let alone do any other real work
>
On Mon, Oct 28, 2013 at 05:48:55PM +0100, Andres Freund wrote:
> On 2013-10-28 12:42:28 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane wrote:
> > >> The idea I'm thinking about at the moment is that toast tokens of this
> > >> sort might each conta
On Thu, Oct 24, 2013 at 12:22:59PM -0400, Robert Haas wrote:
> On Thu, Oct 24, 2013 at 11:40 AM, k...@rice.edu wrote:
> > On Thu, Oct 24, 2013 at 11:07:38AM -0400, Robert Haas wrote:
> >> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao
> >> wrote:
> >> >
On Thu, Oct 24, 2013 at 11:07:38AM -0400, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao wrote:
> > So, our consensus is to introduce the hooks for FPW compression so that
> > users can freely select their own best compression algorithm?
> > Also, probably we need to implement
On Thu, Oct 24, 2013 at 10:28:43AM +0530, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> > Hi
> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add
> > that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to f
On Wed, Oct 16, 2013 at 01:42:34PM +0900, KONDO Mitsumasa wrote:
> (2013/10/15 22:01), k...@rice.edu wrote:
> >Google's lz4 is also a very nice algorithm with 33% better compression
> >performance than snappy and 2X the decompression performance in some
> >benchmar
On Tue, Oct 15, 2013 at 11:02:39AM -0400, Robert Haas wrote:
> >> goals may be in conflict; we'll have to pick something.
> >
> > Note that parsing COPYs is a major PITA from most languages...
> >
> > Perhaps we should make the default output json instead? With every
> > action terminated by a null
On Tue, Oct 15, 2013 at 03:11:22PM +0900, KONDO Mitsumasa wrote:
> (2013/10/15 13:33), Amit Kapila wrote:
> >Snappy is good mainly for un-compressible data, see the link below:
> >http://www.postgresql.org/message-id/CAAZKuFZCOCHsswQM60ioDO_hk12tA7OG3YcJA8v=4yebmoa...@mail.gmail.com
> This result w
On Mon, Oct 07, 2013 at 12:41:58AM +0200, Tomas Vondra wrote:
> > 2. Consider using a simpler/faster hash function, like FNV[1] or Jenkins[2].
> >For fun, try not hashing those ints at all and see how that performs
> > (that,
> >I think, is what you get from HashSet in Java/C#).
>
> I've
On Thu, Sep 05, 2013 at 09:53:18AM -0700, Joshua D. Drake wrote:
>
> On 09/05/2013 09:42 AM, Josh Berkus wrote:
> >
> >Peter,
> >
> >>Other ideas? Are there legitimate uses for SQL_ASCII?
> >
> >Migrating from MySQL. We've had some projects where we couldn't fix
> >MySQL's non-enforcement text g
On Thu, Sep 05, 2013 at 09:42:17AM -0700, Josh Berkus wrote:
> Peter,
>
> > Other ideas? Are there legitimate uses for SQL_ASCII?
>
> Migrating from MySQL. We've had some projects where we couldn't fix
> MySQL's non-enforcement text garbage, and had to use SQL_ASCII on the
> receiving side. If
On Thu, Sep 05, 2013 at 08:47:32AM -0400, Peter Eisentraut wrote:
> Can we consider getting rid of the SQL_ASCII server-side "encoding"? I
> don't see any good use for it, and it's often a support annoyance, and
> it leaves warts all over the code. This would presumably be a
> multi-release effor
On Fri, Aug 30, 2013 at 03:22:37AM +0300, Ants Aasma wrote:
> On Fri, Aug 30, 2013 at 3:02 AM, Andres Freund wrote:
> > I am not sure "hot cache large buffer performance" is really the
> > interesting case. Most of the XLogInsert()s are pretty small in the
> > common workloads. I vaguely recall tr
On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
> 2013/8/29 Alexander Korotkov :
> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
> >>
> >> 2013/8/28 Oleg Bartunov :
> >> > btw, there is serious problem with row-level security and constraints.
> >> > For
> >> > example, user
On Sun, Jul 21, 2013 at 11:30:54AM -0700, Josh Berkus wrote:
> Noah,
>
> > Attached patch just restores the old behavior. Would it be worth preserving
> > the ability to fix an index consistency problem with a REINDEX independent
> > from related heap consistency problems such as duplicate keys?
On Wed, Jun 26, 2013 at 03:47:43PM +0200, Markus Wanner wrote:
> On 06/25/2013 11:52 PM, Kevin Grittner wrote:
> > At least until we have parallel
> > query execution. At *that* point this all changes.
>
> Can you elaborate on that, please? I currently have a hard time
> imagining how partitions
On Mon, Jun 03, 2013 at 04:09:29PM +0100, Martin Schäfer wrote:
>
> > > If I change the strCreate query and add double quotes around the column
> > name, then the problem disappears. But the original name is already in
> > lowercase, so I think it should also work without quoting the column name.
On Mon, Jun 03, 2013 at 03:40:14PM +0100, Martin Schäfer wrote:
> I try to create database columns with umlauts, using the UTF8 client
> encoding. However, the server seems to mess up the column names. In
> particular, it seems to perform a lowercase operation on each byte of the
> UTF-8 multi-b
On Sun, May 12, 2013 at 07:41:26PM -0500, Jon Nelson wrote:
> On Sun, May 12, 2013 at 3:46 PM, Jim Nasby wrote:
> > On 5/10/13 1:06 PM, Jeff Janes wrote:
> >>
> >> Of course the paranoid DBA could turn off restart_after_crash and do a
> >> manual investigation on every crash, but in that case the
On Sun, May 12, 2013 at 03:46:00PM -0500, Jim Nasby wrote:
> On 5/10/13 1:06 PM, Jeff Janes wrote:
> >Of course the paranoid DBA could turn off restart_after_crash and do a
> >manual investigation on every crash, but in that case the database would
> >refuse to restart even in the case where it p
On Wed, May 01, 2013 at 01:52:43PM -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Once upon a time we had multiple books as documentation, then at some
> > point we merged them. It was quite a few years ago.
> > I would agree at this point that we need to consider breaking them up
> > ag
On Thu, Apr 04, 2013 at 04:16:12PM -0400, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > It does look like reducing bucket depth, as I outlined before through
> > the use of a 2-level hashing system, might help speed up
> > ExecScanHashBucket, as it would hopefully have very
On Mon, Mar 04, 2013 at 01:00:09PM -0800, Jeff Davis wrote:
> On Mon, 2013-03-04 at 22:27 +0200, Heikki Linnakangas wrote:
> > If you're serious enough about your data that you want checksums, you
> > should be able to choose your filesystem.
>
> I simply disagree. I am targeting my feature at ca
On Mon, Jan 07, 2013 at 01:36:33PM +, Greg Stark wrote:
> On Mon, Jan 7, 2013 at 10:21 AM, John R Pierce wrote:
> > On 1/7/2013 2:05 AM, Andres Freund wrote:
> >>
> >> I think there should be enough bits available in the toast pointer to
> >> indicate the type of compression. I seem to remembe
On Mon, Jan 07, 2013 at 09:10:31AM +, Simon Riggs wrote:
> On 7 January 2013 07:29, Takeshi Yamamuro
> wrote:
>
> > Anyway, the compression speed in lz4 is very fast, so in my
> > opinion, there is a room to improve the current implementation
> > in pg_lzcompress.
>
> So why don't we use LZ4
On Tue, Nov 06, 2012 at 04:04:51PM -0500, Christopher Browne wrote:
> It seems not unusual for Linux distributions to supply libpq as part of a
> separate package (whether via dpkg, which I think uses "ar" as the
> archiver, or RPM, which uses cpio).
>
> Possibly this is already provided on your s
On Mon, Oct 15, 2012 at 11:46:40AM -0700, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
> >
> > I would be in favor of moving them to contrib for 9.4. Assuming that
> > someone can figure out how this interacts with the existing system table
> > opclasses. Them being i
On Mon, Oct 15, 2012 at 10:13:24AM -0400, Robert Haas wrote:
> On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
> > * Put WARNINGs in the docs against the use of hash indexes, backpatch
> > to 8.3. CREATE INDEX gives no warning currently, though Index Types
> > does mention a caution.
>
> I'd
On Wed, Oct 10, 2012 at 10:21:51PM +0200, Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions -
On Wed, Sep 19, 2012 at 02:39:12PM -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > Robert Haas writes:
> >> It still seems like awfully weird behavior.
> >
> > Why? The WHERE condition relates only to the output of the _stats
> > subquery, so why shouldn't it be evaluated there, rather than
On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch wrote:
> >> Overall, though, I think it best to plug this. We could set a flag before
> >> each operation, like evaluation of SQL arithmetic, for which SIGFPE is
> >>
On Mon, Jun 25, 2012 at 09:45:26PM +0200, Florian Pflug wrote:
> On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
> > Magnus Hagander writes:
> >> Or that it takes less code/generates cleaner code...
> >
> > So we're talking about some LZO things such as snappy from google, and
> > that would b
On Mon, Jun 25, 2012 at 03:12:46PM +0200, Florian Pflug wrote:
> On Jun25, 2012, at 04:04 , Robert Haas wrote:
> > If, for
> > example, someone can demonstrate that an awesomebsdlz compresses 10x
> > as fast as OpenSSL... that'd be pretty compelling.
>
> That, actually, is demonstrably the case f
On Sat, Jun 16, 2012 at 11:15:30AM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane wrote:
> >> It's not obvious to me that we actually *need* anything except the
> >> ability to recognize that a null-encrypted SSL connection probably
> >> shouldn't
On Fri, Jun 15, 2012 at 07:18:34AM -0500, Merlin Moncure wrote:
> On Fri, Jun 15, 2012 at 5:48 AM, Florian Pflug wrote:
> > On Jun15, 2012, at 12:09 , Magnus Hagander wrote:
> >> On Fri, Jun 15, 2012 at 5:52 PM, Florian Pflug wrote:
> >>> On Jun15, 2012, at 07:50 , Magnus Hagander wrote:
> S
On Thu, Jun 14, 2012 at 02:38:02PM -0500, Merlin Moncure wrote:
> On Thu, Jun 14, 2012 at 1:43 PM, Tom Lane wrote:
> > So I've got very little patience with the idea of "let's put in some
> > hooks and then great things will happen". It would be far better all
> > around if we supported exactly o
On Wed, Apr 11, 2012 at 01:53:06AM +0100, Peter Geoghegan wrote:
> On 11 April 2012 01:16, Tom Lane wrote:
> > Peter Geoghegan writes:
> >> On 11 April 2012 00:35, Robert Haas wrote:
> >>> If people need something like that, couldn't they create it by hashing
> >>> the normalized query text with
On Tue, Apr 10, 2012 at 02:01:02PM -0400, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
> >>> Huh? I understood what you said upthread to be that we have two ways
> >>> in existing releases (an
On Thu, Mar 15, 2012 at 10:14:12PM +, Simon Riggs wrote:
> On Wed, Mar 14, 2012 at 6:06 PM, Daniel Farina wrote:
>
> > If we're curious how it affects replication
> > traffic, I could probably gather statistics on LZO-compressed WAL
> > traffic, of which we have a pretty huge amount captured.
On Wed, Mar 14, 2012 at 04:43:55PM -0400, Andrew Dunstan wrote:
>
>
> On 03/14/2012 04:10 PM, Merlin Moncure wrote:
> >there are plenty of on gpl lz based libraries out there (for example:
> >http://www.fastlz.org/) and always have been. they are all much
> >faster than zlib. the main issue is
On Wed, Mar 14, 2012 at 11:06:16AM -0700, Daniel Farina wrote:
> For 9.3 at a minimum.
>
> The topic of LZO became mired in doubts about:
>
> * Potential Patents
> * The author's intention for the implementation to be GPL
>
> Since then, Google released "Snappy," also an LZ77-class
> implementat
On Wed, Feb 22, 2012 at 10:29:56AM -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, Feb 21, 2012 at 2:00 PM, Pavel Stehule
> > wrote:
> >> I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
> >> expected so ANALYZE should be faster then VACUUM ANALYZE.
>
> > VACUUM ANALYZE
On Tue, Feb 21, 2012 at 12:14:03PM -0800, David E. Wheeler wrote:
> On Feb 21, 2012, at 12:11 PM, Michael Glaesemann wrote:
>
> > And hashtext *has* changed across versions, which is why Peter Eisentraut
> > published a version-independent hash function library:
> > https://github.com/petere/pgv
On Mon, Feb 20, 2012 at 10:18:31AM +0100, Marc Mamin wrote:
> > I looked into the complaint here of poor estimation for GIN
> indexscans:
> > http://archives.postgresql.org/pgsql-performance/2012-02/msg00028.php
> > At first glance it sounds like a mistake in selectivity estimation,
> > but it isn'
On Wed, Feb 01, 2012 at 04:12:58PM -0600, Jim Nasby wrote:
> On Jan 26, 2012, at 9:32 PM, Robert Haas wrote:
> > But if we want to put it on a diet, the first thing I'd probably be
> > inclined to lose is the float4 specialization. Some members of the
> > audience will recall that I take dim view
On Tue, Dec 20, 2011 at 02:54:32PM +0100, Magnus Hagander wrote:
> On Tue, Dec 20, 2011 at 14:47, k...@rice.edu wrote:
> > On Tue, Dec 20, 2011 at 02:41:54PM +0100, Magnus Hagander wrote:
> >> On Tue, Dec 20, 2011 at 14:38, Robert Haas wrote:
> >> > On Tue, D
On Tue, Dec 20, 2011 at 02:41:54PM +0100, Magnus Hagander wrote:
> On Tue, Dec 20, 2011 at 14:38, Robert Haas wrote:
> > On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander
> > wrote:
> >> Is there any reason why the setting synchronize_seqscans is in the
> >> section "version/platform compatibilit
On Tue, Nov 22, 2011 at 11:47:22PM +0200, Mikko Tiihonen wrote:
> Hi,
>
> During conversion of the jdbc driver to use binary encoding when receiving
> array objects from postgres it was noticed
> that for example for int[] arrays the binary encoding is normally 30% to 200%
> larger in bytes than
On Tue, Nov 08, 2011 at 04:19:02PM +0100, Albe Laurenz wrote:
> Tom Lane wrote:
> > I distinctly recall us getting bashed a few years ago because there
> > wasn't any convenient way to turn SSL compression *on*. Now that SSL
> > finally does the sane thing by default, you want to turn it off?
> >
On Tue, Nov 08, 2011 at 04:59:02PM +0100, Albe Laurenz wrote:
> Tom Lane wrote:
> > There might be some argument for providing a client option to disable
> > compression, but it should not be forced, and it shouldn't even be the
> > default. But before adding YA connection option, I'd want to see
On Tue, Sep 13, 2011 at 03:02:57PM +0200, Florian Pflug wrote:
> On Sep13, 2011, at 14:58 , k...@rice.edu wrote:
> > It will be interesting to see if there are any performance ramifications to
> > this new write function.
>
> What would those be? For non-interruptible
On Tue, Sep 13, 2011 at 01:30:34PM +0200, Florian Pflug wrote:
> On Sep13, 2011, at 13:07 , Florian Pflug wrote:
> > Here's my suggested implementation for pg_write_nointr. pg_read_nointr
> > should be similar
> > (but obviously without the ENOSPC handling)
> >
> >
>
> Sorry for the self-reply.
On Mon, Sep 12, 2011 at 04:46:53PM +1000, George Barnett wrote:
> On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
>
> > If you really meant to say "intr" there (and not "nointr") then that
> > probably explains the partial writes.
> >
> > Still, I agree with Noah and Kevin that we ought to deal
On Fri, Sep 02, 2011 at 04:27:46PM -0500, Ross J. Reedstrom wrote:
> On Fri, Sep 02, 2011 at 02:05:45PM -0500, k...@rice.edu wrote:
> > On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote:
> > > On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote:
> > &g
On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote:
> On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote:
> > Hmm, this thread seems to have petered out without a conclusion. Just
> > wanted to comment that there _are_ non-password storage uses for these
> > digests: I use the
On Wed, Aug 03, 2011 at 03:19:06PM +0200, Petro Meier wrote:
> Normal021false
> falsefalseDEX-NONEX-NONE
>
>
On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 18.07.2011 18:32, Tom Lane wrote:
> >> Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
> >> that that might be a significant limitation.
>
> > Right, we can easily change the time
On Fri, Jul 15, 2011 at 11:37:54PM +0200, Žiga Kranjec wrote:
> Hello!
>
> Recently we have upgraded our debian system (sid),
> which has since started crashing mysteriously.
> We are still looking into that. It runs on 3ware RAID.
> Postgres package is 8.4.8-2.
>
> The database came back up appa
On Tue, Jul 12, 2011 at 04:29:33PM -0400, Andrew Dunstan wrote:
>
>
> On 07/12/2011 03:44 PM, Joshua D. Drake wrote:
> >>
> >>What about extensions makes them less usable?
> >
> >
> >It is an extra step, that is less usable. Does it matter? Shrug, I
> >know I hate having to type apt-get just to u
On Thu, Jun 02, 2011 at 02:58:52PM +0200, Pavel Stehule wrote:
> 2011/6/2 Peter Eisentraut :
> > On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
> >> I partialy implemented following missing LOBs types. Requirement for this
> >> was
> >> to give ability to create (B/C)LOB columns and ad
On Tue, May 31, 2011 at 09:36:00AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> >> We already have a search system that works reasonably well for the
> >> archives...
>
> > I trust this weas a piece of sarcasm. I spoke to more than a few pe
On Tue, May 31, 2011 at 09:33:33AM -0400, Robert Haas wrote:
> On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut wrote:
> > On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
> >> I have used RT and I found that the
> >> web interface was both difficult to use and unwieldly for tickets
> >> con
On Tue, May 31, 2011 at 02:58:02PM +0200, Magnus Hagander wrote:
> On Tue, May 31, 2011 at 14:44, Andrew Dunstan wrote:
> >
> >
> > On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> >>
> >> We already have a search system that works reasonably well for the
> >> archives...
> >>
> >
> > I trust this
On Mon, May 30, 2011 at 09:52:38PM -0400, Robert Haas wrote:
> On Mon, May 30, 2011 at 8:16 PM, Christopher Browne
> wrote:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" wrote:
> >> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:
> >> > I've summarizes the main points made in the recent dis
On Fri, Apr 29, 2011 at 02:10:19PM -0400, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > Uhm.. With the above, perhaps "--%Z+>", which would generate:
> >
> > postgres=>
> > -- +>
>
> yah, obviously not going to work. :) However, it wouldn't be impossible
> to have
97 matches
Mail list logo
