Re: [HACKERS] unique index violation after pg_upgrade to PG10

On Tue, Oct 24, 2017 at 01:30:19PM -0500, Justin Pryzby wrote: > On Tue, Oct 24, 2017 at 01:27:14PM -0500, Kenneth Marshall wrote: > > On Tue, Oct 24, 2017 at 01:14:53PM -0500, Justin Pryzby wrote: > > > > Note: > > > I run a script which does various combinations

Re: [HACKERS] unique index violation after pg_upgrade to PG10

On Tue, Oct 24, 2017 at 01:14:53PM -0500, Justin Pryzby wrote: > I upgrade another instance to PG10 yesterday and this AM found unique key > violations. > > Our application is SELECTing FROM sites WHERE site_location=$1, and if it > doesn't find one, INSERTs one (I know that's racy and not ideal).

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 05:58:41PM -0400, Tom Lane wrote: > Robert Haas writes: > > Attached is a quick sketch of how this could perhaps be done (ignoring > > for the moment the relatively-boring opclass pushups). It introduces > > a new function hash_any_extended which differs from hash_any() in

Re: [HACKERS] WIP: Data at rest encryption

On Wed, Jun 14, 2017 at 12:04:26PM +0300, Aleksander Alekseev wrote: > Hi Ants, > > On Tue, Jun 13, 2017 at 09:07:49AM -0400, Peter Eisentraut wrote: > > On 6/12/17 17:11, Ants Aasma wrote: > > > I'm curious if the community thinks this is a feature worth having? > > > Even considering that securi

Re: [HACKERS] Hash Functions

On Fri, May 12, 2017 at 02:23:14PM -0400, Robert Haas wrote: > > What about integers? I think we're already assuming two's-complement > arithmetic, which I think means that the only problem with making the > hash values portable for integers is big-endian vs. little-endian. > That's sounds solvea

Re: [HACKERS] CTE inlining

On Wed, May 03, 2017 at 02:33:05PM -0300, Alvaro Herrera wrote: > David Fetter wrote: > > > When we add a "temporary" GUC, we're taking on a gigantic burden. > > Either we support it forever somehow, or we put it on a deprecation > > schedule immediately and expect to be answering questions about

Re: [HACKERS] bytea_output output of base64

On Thu, Feb 23, 2017 at 03:52:46PM -0800, David Fetter wrote: > On Thu, Feb 23, 2017 at 05:55:37PM -0500, Bruce Momjian wrote: > > On Thu, Feb 23, 2017 at 04:08:58PM -0500, Tom Lane wrote: > > > Bruce Momjian writes: > > > > Is there a reason we don't support base64 as a bytea_output output > > >

Re: [HACKERS] Hash Indexes

On Mon, Sep 19, 2016 at 12:14:26PM +0530, Amit Kapila wrote: > On Mon, Sep 19, 2016 at 11:20 AM, Mark Kirkwood > wrote: > > > > > > On 17/09/16 06:38, Andres Freund wrote: > >> > >> On 2016-09-16 09:12:22 -0700, Jeff Janes wrote: > >>> > >>> On Thu, Sep 15, 2016 at 7:23 AM, Andres Freund > >>> wr

Re: [HACKERS] README of hash index

On Fri, Sep 16, 2016 at 04:50:53PM +0530, Amit Kapila wrote: > Currently README of hash module contain algorithms written in below form. > > The insertion algorithm is rather similar: > > pin meta page and take buffer content lock in shared mode > loop: > compute bucket number for target hash key

[HACKERS] Hash index with larger hashes

Hello Developers, I have been following the recent discussions on increasing the size of the hash function used in Postgres and the work to provide WAL and performance improvements for hash indexes. I know it was mentioned when we moved to the new hashing functions, but the existing functions do

Re: [HACKERS] pg_basebackup wish list

On Tue, Jul 12, 2016 at 11:06:39AM -0700, Jeff Janes wrote: > On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut > wrote: > > On 7/12/16 12:53 PM, Jeff Janes wrote: > >> The --help message for pg_basebackup says: > >> > >> -Z, --compress=0-9 compress tar output with given compression level > >

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 06:04:09PM +0100, Dave Page wrote: > On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote: > > [ man, this thread has totally outlived its title, could we change that? > > ?I'll start with this subtopic ] > > > > Robert Haas writes: > >> In fact, I've been wondering if we shoul

Re: [HACKERS] Correctly producing array literals for prepared statements

On Wed, Feb 23, 2011 at 03:34:45PM -0500, Andrew Chernow wrote: > On 2/23/2011 3:06 PM, Peter Geoghegan wrote: >> On 23 February 2011 15:34, Merlin Moncure wrote: >>> You can send nested arrays safely. You just have to be very formal >>> about escaping *everything* both as you get it and as it go

Re: [HACKERS] Correctly producing array literals for prepared statements

On Wed, Feb 23, 2011 at 09:34:06AM -0600, Merlin Moncure wrote: > On Tue, Feb 22, 2011 at 10:16 PM, Peter Geoghegan > wrote: > > I'm investigating the possibility of developing a utility function for > > our C++ client library, libpqxx, that produces array literals that can > > be used in prepared

Re: [HACKERS] LIKE, CHAR(), and trailing spaces

On Wed, Feb 02, 2011 at 07:48:38PM -0500, Bruce Momjian wrote: > Brendan Jurd wrote: > > On 3 February 2011 10:54, Bruce Momjian wrote: > > > It seems LIKE is considering the trailing CHAR(10) field spaces as > > > significant, even though our documentations says: > > > > > -- snip -- > > > > > >

Re: [HACKERS] Why is sorting on two columns so slower thansortingon one column?

On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote: > - Original Message - > From: "Kenneth Marshall" > To: "Li Jie" > Cc: "pgsql-hackers" > Sent: Thursday, December 23, 2010 10:30 PM > Subject: Re: [HACKERS] Why is sorting on t

Re: [HACKERS] Why is sorting on two columns so slower than sortingon one column?

On Thu, Dec 23, 2010 at 10:19:46PM +0800, Li Jie wrote: > Hi Ken, > > Thanks for your tips! Yes it is the case, and I run another query sorting on > the second column whose values are random. > > postgres=# explain analyze select * from big_wf order by id; >

Re: [HACKERS] Why is sorting on two columns so slower than sorting on one column?

On Thu, Dec 23, 2010 at 02:33:12AM -0500, Jie Li wrote: > Hi, > > Here is the test table, > > postgres=# \d big_wf > Table "public.big_wf" > Column | Type | Modifiers > +-+--- > age| integer | > id | integer | > > postgres=# \dt+ big_wf >

Re: [HACKERS] [FeatureRequest] Base Convert Function

On Tue, Dec 21, 2010 at 11:28:17PM +0200, Pavel Golub wrote: > Hello, Pavel. > > You wrote: > > PS> Hello > > PS> Dne 21. prosince 2010 21:11 Tom Mudru??ka > napsal(a): > >> > >> Thx for you answers :-) > >> Well... i know that i can write my own plugin and i am familiar with C so > >> thi

Re: [HACKERS] Extensions, patch v20 (bitrot fixes)

On Mon, Dec 20, 2010 at 03:08:48PM -0500, Tom Lane wrote: > Kenneth Marshall writes: > > On Mon, Dec 20, 2010 at 02:10:39PM -0500, Tom Lane wrote: > >> [citation needed]? Exactly what characters are missing, and why would > >> the Unicode people have chosen to lea

Re: [HACKERS] Extensions, patch v20 (bitrot fixes)

On Mon, Dec 20, 2010 at 02:10:39PM -0500, Tom Lane wrote: > David Fetter writes: > > On Mon, Dec 20, 2010 at 08:01:42PM +0100, Martijn van Oosterhout wrote: > >> I think you mean Unicode is not a superset of all character sets. I've > >> heard this before but never found what's missing. [citation

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 09:39:12AM -0500, Tom Lane wrote: > Magnus Hagander writes: > > I'm sure this has been up before, but hey, let's take it another round. > > Why don't we change the default shutdown mode for pg_ctl from "smart" > > to "fast"? I've never come across a single usecase where "sm

Re: [HACKERS] Why percent_rank is so slower than rank?

On Thu, Dec 09, 2010 at 05:18:57PM -0500, Tom Lane wrote: > I wrote: > > We're throwing away one tuple at a time as we advance forward through > > the tuplestore, and moving 10+ tuple pointers each time. Ugh. > > This code was all right when written, because (IIRC) the mergejoin > > case was a

Re: [HACKERS] Suggesting a libpq addition

On Mon, Dec 06, 2010 at 10:14:55AM -0500, Merlin Moncure wrote: > On Mon, Dec 6, 2010 at 9:55 AM, Marc Balmer wrote: > > Am 06.12.10 15:37, schrieb Merlin Moncure: > >> On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander > >> wrote: > >>> On Sun, Dec 5, 2010 at 10:22, Marc Balmer wrote: > I am

Re: [HACKERS] Report: Linux huge pages with Postgres

On Sat, Nov 27, 2010 at 02:27:12PM -0500, Tom Lane wrote: > We've gotten a few inquiries about whether Postgres can use "huge pages" > under Linux. In principle that should be more efficient for large shmem > regions, since fewer TLB entries are needed to support the address > space. I spent a bi

Re: [HACKERS] unlogged tables

On Wed, Nov 17, 2010 at 02:16:06PM -0500, Tom Lane wrote: > Robert Haas writes: > > On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane wrote: > >> Robert is probably going to object that he wanted to prevent any > >> fsyncing for unlogged tables, but the discussion over in pgsql-general > >> is crystal cl

Re: [HACKERS] Protecting against unexpected zero-pages: proposal

On Tue, Nov 09, 2010 at 02:05:57PM -0500, Robert Haas wrote: > On Tue, Nov 9, 2010 at 12:31 PM, Greg Stark wrote: > > On Tue, Nov 9, 2010 at 5:06 PM, Aidan Van Dyk wrote: > >> So, for getting checksums, we have to offer up a few things: > >> 1) zero-copy writes, we need to buffer the write to get

Re: [HACKERS] Hash support for arrays

On Thu, Nov 04, 2010 at 10:00:40AM +, Dean Rasheed wrote: > On 3 November 2010 09:24, Nicolas Barbier wrote: > > 2010/11/2 Kenneth Marshall : > > > >> Given that our hash implimentation mixes the input data well (It does. > >> I tested it.) then a simple

Re: [HACKERS] Hash support for arrays

On Wed, Nov 03, 2010 at 10:24:16AM +0100, Nicolas Barbier wrote: > 2010/11/2 Kenneth Marshall : > > > Given that our hash implimentation mixes the input data well (It does. > > I tested it.) then a simple rotate-and-xor method is all that should > > be needed to ma

Re: [HACKERS] Hash support for arrays

On Tue, Nov 02, 2010 at 04:42:19PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane wrote: > >> Really? ?I think "I don't understand when this fails" isn't obviously > >> better than being able to predict when it fails ... > > > Isn't that the whole poin

Re: [HACKERS] PostgreSQL and HugePage

On Wed, Oct 20, 2010 at 10:10:00AM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 19, 2010 at 11:30 PM, daveg wrote: > >> On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote: > >>> Heh - provided you specify > >>> SHM_HUGETLB > >>> in the relevant call that is :-) > > >>

Re: [HACKERS] Why do we have a database specification in .pgpass?

On Thu, Oct 14, 2010 at 06:09:35AM +0200, Dennis Bj??rklund wrote: > > We have a database specification in .pgpass: > > > > hostname:port:database:username:password > > > > What is the purpose of 'database' since username/password combinations > > are global, not per database? I would like to

Re: [HACKERS] Why is time with timezone 12 bytes?

On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote: > On 22 September 2010 22:01, Josh Berkus wrote: > > All, > > > > I was just checking on our year-2027 compliance, and happened to notice > > that time with time zone takes up 12 bytes. ?This seems peculiar, given > > that timestamp with

Re: [HACKERS] Another Modest Proposal: Platforms

On Wed, Sep 22, 2010 at 01:17:54PM -0700, David Fetter wrote: > Folks, > > While it's interesting to note, in an historical sense, that a > platform most recently updated when 1999 was still in the future, I > think it's time we did a little pruning. > > We can start by supporting only platforms

Re: [HACKERS] beta3 & the open items list

On Sun, Jun 20, 2010 at 03:01:04PM -0500, Kevin Grittner wrote: > "Joshua D. Drake" wrote: > > > Can someone tell me what we are going to do about firewalls that > > impose their own rules outside of the control of the DBA? > > Has anyone actually seen a firewall configured for something so >

Re: [HACKERS] BYTEA / DBD::Pg change in 9.0 beta

On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote: > On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner > wrote: > > On 05/19/2010 08:13 AM, Tom Lane wrote: > >> Bernd Helmle writes: > >>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote: > May I ask whats the reason is for

Re: [HACKERS] BYTEA / DBD::Pg change in 9.0 beta

On Tue, May 18, 2010 at 03:26:17PM -0600, Alex Hunsaker wrote: > On Tue, May 18, 2010 at 15:20, Jesper Krogh wrote: > > On 2010-05-18 23:12, Alex Hunsaker wrote: > >> > >> set bytea_output 'escape'; > > > > That was it. Knowing what the problem was I had no problem finding it in the > > release no

Re: [HACKERS] Generating Lots of PKs with nextval(): A Feature Proposal

Hi Peter, All you need to do is define your own sequence with an increment of 500. Look at: http://www.postgresql.org/docs/8.4/static/sql-createsequence.html Regards, Ken On Fri, May 14, 2010 at 02:56:18PM -0400, Peter Crabtree wrote: > Recently, in preparation for migrating an application to p

[HACKERS] construct_array() use with PQexec with binary data

Dear PostgreSQL development community, I am working on adapting a regular PQexec() call to use binary transmission of the parameters. One of the parameters is an array of BIGINT. Looking in include/utils/array.h, it appears that construct_array() will do exactly what I need to get an array to pass

Re: [HACKERS] Can we still trust plperl?

On Thu, Mar 11, 2010 at 09:31:46AM -0500, Andrew Dunstan wrote: > > Last night my attention was drawn to this: > > > > I'm wondering if we can reasonably continue to support plperl as a trusted > lang

Re: [HACKERS] pgbouncer + psql 9.0a4

Hi Garick, Add an ignore_startup_parameters to your pgbouncer.ini file with application_name. Cheers, Ken On Fri, Feb 26, 2010 at 11:26:23AM -0500, Garick Hamlin wrote: > I was just trying out 9.0a4 and I noticed. That I can't connect to > pgbouncer with psql from 9.0a4 as a result of the set

Re: [HACKERS] Avoiding bad prepared-statement plans.

On Thu, Feb 18, 2010 at 08:31:05PM -0600, David Christensen wrote: > > On Feb 18, 2010, at 2:19 PM, Pierre C wrote: > >> >>> What about catching the error in the application and INSERT'ing into the >>> current preprepare.relation table? The aim would be to do that in dev or >>> in pre-prod environm

Re: [HACKERS] Union test case broken in make check?

Without an order by, the order is not defined. The answers are the same but the test gives a false failure because of the lack of ordering. Regards, Ken On Thu, Nov 19, 2009 at 07:54:30PM -0500, Emmanuel Cecchet wrote: > Tom Lane wrote: >> Andrew Dunstan writes: >> >>> Emmanuel Cecchet wrote:

Re: [HACKERS] [PATCH] tsearch parser inefficiency if text includes urls or emails - new version

On Sun, Nov 08, 2009 at 05:00:53PM +0100, Andres Freund wrote: > On Sunday 01 November 2009 16:19:43 Andres Freund wrote: > > While playing around/evaluating tsearch I notices that to_tsvector is > > obscenely slow for some files. After some profiling I found that this is > > due using a seperate

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote: > Hannu Krosing writes: > > I had never checked the docs for hash functions, but I had assumed, that > > internal functions are prefixed by pg_ and anything else is public, free > > to use functionality. > > Sure, it's free to use. It's n

Re: [HACKERS] Proposal: String key space for advisory locks

On Mon, Oct 26, 2009 at 06:35:13PM -0700, Christophe Pettus wrote: > > On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote: > >> Hmmm, hashtext() returns int32. , >> Can you reduce the collision issue if we had hashtext64()? > > That would certainly reduce the chance of a collison considerably, ass

Re: [HACKERS] Rejecting weak passwords

On Thu, Oct 01, 2009 at 01:07:04PM -0400, Tom Lane wrote: > Magnus Hagander writes: > > On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote: > >> I agree with the subsequent comments suggesting a sample module that > >> actually does something useful --- although if it's going to link to > >> external c

Re: [HACKERS] Rejecting weak passwords

On Thu, Oct 01, 2009 at 03:54:37PM +0200, Magnus Hagander wrote: > On Thu, Oct 1, 2009 at 15:26, Albe Laurenz wrote: > > Andrew Dunstan wrote: > So here's the patch. > I don't think there is documentation required; > correct me if I am wrong. > >>> > >>> How will people know how to

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

On Sat, Aug 22, 2009 at 12:39:41PM -0400, Tom Lane wrote: > Mark Cave-Ayland writes: > > So in conclusion, I think that patch looks good and that the extra time > > I was seeing was due to RECHECK being applied to the && operator, and > > not the time being spent within the index scan itself. >

Re: [HACKERS] Fixing geometic calculation

On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote: > On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote: > > On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote: > > > On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote: > > >

Re: [HACKERS] Fixing geometic calculation

On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote: > On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote: > > Let us consider the ordering of real numbers in postgres. As you can see > > from > > the results below it has clearly returne

Re: [HACKERS] Fixing geometic calculation

On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote: > Let us consider the ordering of real numbers in postgres. As you can see > from > the results below it has clearly returned the correct results. > > select( 1. = 1.0002 ); => f > select( 1.

Re: [HACKERS] Review remove {join,from}_collapse_limit, add enable_join_ordering

On Thu, Jul 16, 2009 at 06:49:08PM +0200, Andres Freund wrote: > On Thursday 16 July 2009 17:59:58 Tom Lane wrote: > > Andres Freund writes: > > > The default settings currently make it relatively hard to trigger geqo at > > > all. > > > > Yes, and that was intentional. One of the implications of

Re: [HACKERS] Re: Review remove {join,from}_collapse_limit, add enable_join_ordering

On Thu, Jul 16, 2009 at 04:27:39PM +0100, Greg Stark wrote: > On Thu, Jul 16, 2009 at 4:16 PM, Tom Lane wrote: > > However, I do observe that this seems a sufficient counterexample > > against the theory that we can just remove the collapse limits and let > > GEQO save us on very complex queries. ?

Re: [HACKERS] WIP: Deferrable unique constraints

On Tue, Jul 14, 2009 at 12:13:33PM -0700, Jeff Davis wrote: > On Tue, 2009-07-14 at 13:29 -0500, Kenneth Marshall wrote: > > I am looking at adding unique support to hash indexes for 8.5 and > > they will definitely need to visit the heap. > > Have you seen

Re: [HACKERS] WIP: Deferrable unique constraints

On Tue, Jul 14, 2009 at 09:56:48AM -0700, Jeff Davis wrote: > On Sun, 2009-07-12 at 14:14 +0100, Dean Rasheed wrote: > > Here is an updated version of this patch which should apply to HEAD, > > with updated docs, regression tests, pg_dump and psql \d. > > > > It works well for small numbers of tem

Re: [HACKERS] *_collapse_limit, geqo_threshold

On Sat, Jul 11, 2009 at 12:23:59PM -0400, Tom Lane wrote: > Andres Freund writes: > > The only question I have is, whether random_r or similar is available on > > enough platforms... Has anybody an idea about this? > > On most unixoid system one could just wrap erand48() if random_r is not > > a

Re: [HACKERS] *_collapse_limit, geqo_threshold

On Wed, Jul 08, 2009 at 05:46:02PM -0400, Tom Lane wrote: > "Kevin Grittner" writes: > > For a moment it seemed logical to suggest a session GUC for the seed, > > so if you got a bad plan you could keep rolling the dice until you got > > one you liked; but my right-brain kept sending shivers down

Re: [HACKERS] *_collapse_limit, geqo_threshold

On Wed, Jul 08, 2009 at 04:13:11PM -0500, Kevin Grittner wrote: > Tom Lane wrote: > > > It occurs to me that one way to make GEQO less scary would be to > > take out the nondeterminism by resetting its random number generator > > for each query. You might get a good plan or an awful one, but a

Re: [HACKERS] *_collapse_limit, geqo_threshold

Hi, When I was first familiarizing myself with PostgreSQL, I took a walk through its documentation on GECO and similar processes in the literature. One big advantage of GECO is that you can trade off planning time for plan optimization. I do agree that it should be updated, but there were definite

Re: [HACKERS] 8.4 open item: copy performance regression?

On Fri, Jun 19, 2009 at 07:49:31PM +0200, Stefan Kaltenbrunner wrote: > Tom Lane wrote: >> Just eyeing the code ... another thing we changed since 8.3 is to enable >> posix_fadvise() calls for WAL. Any of the complaints want to try diking >> out this bit of code (near line 2580 in >> src/backend/

Re: [HACKERS] 8.4 open item: copy performance regression?

Yes, you are right. I thought that they were absolute function counts. The data makes more sense now. Regards, Ken On Thu, Jun 18, 2009 at 07:03:34PM -0500, Kevin Grittner wrote: > Kenneth Marshall wrote: > > > What is not clear from Stefen's function listing is how the 8.4

Re: [HACKERS] 8.4 open item: copy performance regression?

On Thu, Jun 18, 2009 at 05:20:08PM -0400, Tom Lane wrote: > Stefan Kaltenbrunner writes: > > Any objections if I add: > > http://archives.postgresql.org/pgsql-performance/2009-06/msg00215.php > > to the (currently empty) list of open items for 8.4? > > I am unable to duplicate any slowdown on thi

Re: [HACKERS] dot to be considered as a word delimiter?

arch > parser as explained in the documentation here: > http://www.postgresql.org/docs/8.3/static/textsearch-parsers.html > > Thanks, > Sushant. > +1 Ken > On Tue, Jun 2, 2009 at 8:47 AM, Kenneth Marshall wrote: > > > On Mon, Jun 01, 2009 at 08:22:23PM -0500, Kevin Gr

Re: [HACKERS] dot to be considered as a word delimiter?

On Mon, Jun 01, 2009 at 08:22:23PM -0500, Kevin Grittner wrote: > Sushant Sinha wrote: > > > I think that dot should be considered by as a word delimiter because > > when dot is not followed by a space, most of the time it is an error > > in typing. Beside they are not many valid english words

Re: [HACKERS] [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)

On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote: > I forgot to fix contrib. Updated patch attached. > > Zdenek > > Zdenek Kotala pe v p?? 22. 05. 2009 v 16:23 -0400: > > Attached patch cleanups hash index headers to allow compile hasham for > > 8.3 version. It help

Re: [HACKERS] a few crazy ideas about hash joins

On Fri, Apr 03, 2009 at 08:03:33AM -0400, Robert Haas wrote: > On Fri, Apr 3, 2009 at 1:48 AM, Heikki Linnakangas > wrote: > > Robert Haas wrote: > >> > >> While investigating some performance problems recently I've had cause > >> to think about the way PostgreSQL uses hash joins. ?So here are a f

Re: [HACKERS] improving concurrent transactin commit rate

On Wed, Mar 25, 2009 at 05:56:02PM +, Sam Mason wrote: > On Wed, Mar 25, 2009 at 12:01:57PM -0500, Kenneth Marshall wrote: > > On Wed, Mar 25, 2009 at 03:58:06PM +, Sam Mason wrote: > > > #!/bin/bash > > > nclients=$1 > > > ittrs=$2 > > >

Re: [HACKERS] improving concurrent transactin commit rate

On Wed, Mar 25, 2009 at 03:58:06PM +, Sam Mason wrote: > On Wed, Mar 25, 2009 at 02:38:45PM +, Greg Stark wrote: > > Sam Mason writes: > > > Why does it top out so much though? It goes up nicely to around ten > > > clients (I tested with 8 and 12) and then tops out and levels off. The >

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

On Mon, Mar 16, 2009 at 02:30:28PM -0400, Jonah H. Harris wrote: > On Mon, Mar 16, 2009 at 2:26 PM, Jonah H. Harris > wrote: > > > On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera < > > alvhe...@commandprompt.com> wrote: > > > >> We already have one; it's called update_process_title. > > > > > >

Re: [HACKERS] Problem with accesing Oracle from plperlu function when using remote pg client.

On Mon, Mar 16, 2009 at 03:16:07PM +0100, Tomasz Olszak wrote: > Greetings to All! > > I've tried to find solution of my problem on other pg mailing lists but > without bigger effect. > > I have a table A in PG. There is also table A in Oracle. > I want to import specific row from oracle to p

Re: [HACKERS] libxml incompatibility

On Fri, Mar 06, 2009 at 05:23:45PM -0300, Alvaro Herrera wrote: > Kenneth Marshall wrote: > > This looks like a problem caused by two different libxml versions: > > the one used for the perl XML::LibXML wrappers and the one used to > > build PostgreSQL. They really need to

Re: [HACKERS] libxml incompatibility

On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote: > > > Alvaro Herrera wrote: >> Hi, >> >> It seems that if you load libxml into a backend for whatever reason (say >> you create a table with a column of type xml) and then create a plperlu >> function that "use XML::LibXML", we get a s

Re: [HACKERS] libxml incompatibility

This looks like a problem caused by two different libxml versions: the one used for the perl XML::LibXML wrappers and the one used to build PostgreSQL. They really need to be the same. Does it still segfault if they are identical? Regards, Ken On Fri, Mar 06, 2009 at 04:14:04PM -0300, Alvaro Herr

Re: [HACKERS] pg_restore --multi-thread

On Fri, Feb 20, 2009 at 09:22:58AM -0800, Joshua D. Drake wrote: > On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote: > > > The short answer is that we don't know yet. There is anecdotal evidence > > that the number of CPUs on the server is a good place to start, but we > > should be hones

Re: [HACKERS] WIP: hooking parser

On Thu, Feb 19, 2009 at 06:29:25PM +, Sam Mason wrote: > On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote: > > Peter Eisentraut writes: > > > I'd be quite interested to support some kind of hook to deal with this > > > Oracle null issue. It would be a great help for porting projects.

Re: [HACKERS] [PERFORM] GIST versus GIN indexes for intarrays

On Fri, Feb 13, 2009 at 04:12:53PM +0300, Teodor Sigaev wrote: >> The short-term workaround for Rusty is probably to create his GIN >> index using the intarray-provided gin__int_ops opclass. But it > Right >> seems to me that we ought to get rid of intarray's @> and <@ operators >> and have the mo

Re: [HACKERS] on hash indexes

On Wed, Feb 04, 2009 at 11:22:44PM +0100, Zdenek Kotala wrote: > The main speed improvement is for varchar datatype. I think It should be > mention here as well. IIRC, times are similar with B-Tree for integer > datatype. > > Zdenek > > Kenneth Marshall pe v st

Re: [HACKERS] on hash indexes

I had submitted the documentation change as part of my hash function patch but it was removed as not relevant. (It wasn't really.) I would basically remove the first sentence: Note: Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX

Re: [HACKERS] pg_upgrade project status

On Tue, Jan 27, 2009 at 04:23:18PM +0100, Harald Armin Massa wrote: > > I think it's fairly easy to install Perl on Windows actually. It > > doesn't sound too onerous a requirement if you want in-place upgrade; > > actually it looks a very reasonable one. > > > > Much more reasonable than Korn she

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sun, Jan 25, 2009 at 10:27:03PM -0600, Kenneth Marshall wrote: > On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote: > > Jeff Davis writes: > > > I ran 5 times on both old and new code, eliminating the top and bottom > > > and taking the average of the r

Re: [HACKERS] pg_upgrade project status

On Tue, Jan 27, 2009 at 11:39:50AM -0300, Alvaro Herrera wrote: > Heikki Linnakangas wrote: > > Andrew Dunstan wrote: > >> Zdenek Kotala wrote: > >>> 2) pg_upgrade.sh > >>> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php > >>> > >>> Pg_upgrade.sh is shell script for catalog conver

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote: > Jeff Davis writes: > > I ran 5 times on both old and new code, eliminating the top and bottom > > and taking the average of the remaining 3, and I got a 6.9% performance > > improvement with the new code. > > The question that has been c

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote: > Tom Lane writes: > > > Jeff Davis writes: > >> I ran 5 times on both old and new code, eliminating the top and bottom > >> and taking the average of the remaining 3, and I got a 6.9% performance > >> improvement with the new code.

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sat, Jan 10, 2009 at 10:56:15AM -0800, Jeff Davis wrote: > On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote: > > Jeff Davis writes: > > > I ran 5 times on both old and new code, eliminating the top and bottom > > > and taking the average of the remaining 3, and I got a 6.9% performance > > > i

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Fri, Jan 09, 2009 at 02:00:39PM -0800, Jeff Davis wrote: > On Fri, 2009-01-09 at 14:29 -0600, Kenneth Marshall wrote: > > Jeff, > > > > Thanks for the review. I would not really expect any differences in hash > > index build times other than normal noise var

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Fri, Jan 09, 2009 at 12:04:15PM -0800, Jeff Davis wrote: > On Mon, 2008-12-22 at 13:47 -0600, Kenneth Marshall wrote: > > Dear PostgreSQL developers, > > > > I am re-sending this to keep this last change to the > > internal hash function on the radar. > >

Re: [HACKERS] float8 strtod weirdness

On Wed, Jan 07, 2009 at 08:12:44PM +0530, Nikhil Sontakke wrote: > Hi, > > Consider the following with latest CVS sources: > > postgres=# create table temp(val float4); > CREATE TABLE > postgres=# insert into temp values (415.1); > INSERT 0 1 > postgres=# select * from temp where val = 415.1; >

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Dear PostgreSQL developers, I am re-sending this to keep this last change to the internal hash function on the radar. Ken Sorry about the delay for this update to the new hash index implementation. I was trying to get the WAL logging in place and forgot to post the actual patch. The

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

On Wed, Dec 17, 2008 at 05:10:40PM -0600, Kenneth Marshall wrote: > On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote: > > On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote: > > > Rebuilding a hash index for the case > > > for which it is preferred

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote: > On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote: > > Rebuilding a hash index for the case > > for which it is preferred (large, large tables) would be excrutiating. > > > > there's such a si

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

On Wed, Dec 17, 2008 at 10:58:11PM +, Simon Riggs wrote: > > On Wed, 2008-12-17 at 16:47 -0600, Kenneth Marshall wrote: > > > I think having your index survive a server power outage or other > > crash is a very good thing. Rebuilding a hash index for the case > >

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

On Wed, Dec 17, 2008 at 05:42:41PM -0500, Jaime Casanova wrote: > On Wed, Dec 17, 2008 at 4:26 PM, Simon Riggs wrote: > > Hot Standby won't work with hash indexes because they are > > non-recoverable. > > > > We have a number of ways of dealing with this: > > > > i don't see a reason for inventin

Re: [HACKERS] cvs head initdb hangs on unixware

Would it be reasonable to turn of optimization for this file? Ken On Tue, Dec 09, 2008 at 05:47:47PM +0100, [EMAIL PROTECTED] wrote: > On Tue, 9 Dec 2008, Tom Lane wrote: > >> Date: Tue, 09 Dec 2008 09:23:06 -0500 >> From: Tom Lane <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Cc: Heikki Linnak

Re: [HACKERS] WIP parallel restore patch

On Thu, Nov 20, 2008 at 02:26:14PM -0500, Andrew Dunstan wrote: > > > Kenneth Marshall wrote: >> Okay, I have had a chance to run some timing benchmarks. >> Here are my results for the parallel pg_restore patch: >> >> Ken >> --

Re: [HACKERS] WIP parallel restore patch

Okay, I have had a chance to run some timing benchmarks. Here are my results for the parallel pg_restore patch: Ken -- Server settings: max_connections = 100 # (change requires restart) shared_buffers = 256MB

Re: [HACKERS] [RRR] Tests citext casts - reviewed

The patch for the citext tests applied to module cleanly and the patched files resulted in a clean "make installcheck" run for the citext module. My previous problem was the result of not testing with a C locale database. This patch is ready to be applied. Regards, Ken Marshall -- Sent via pgsql

Re: [RRR] [HACKERS] Tests citext casts

On Fri, Nov 07, 2008 at 10:15:17AM -0800, David E. Wheeler wrote: > On Nov 5, 2008, at 12:34 PM, Kenneth Marshall wrote: > >> I am using the anonymous CVS repository, it returns the following >> information in pg_catalog.pg_settings: > > What is lc_collate set to? > &g

Re: [RRR] [HACKERS] Tests citext casts

On Wed, Nov 05, 2008 at 09:04:04AM -0800, David E. Wheeler wrote: > On Nov 5, 2008, at 6:40 AM, Kenneth Marshall wrote: > >> I installed and ran the citext tests both with and without >> the patch and had failures both times. The patch applied >> cleanly and the "

[HACKERS] Tests citext casts

I installed and ran the citext tests both with and without the patch and had failures both times. The patch applied cleanly and the "make;make install" completed without errors. I have attached the two regression.diffs files, one without the patch applied and the other with the patch. Regards, Ken

  1   2   3   >