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

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

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

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

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

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

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

[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

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 t...@sss.pgh.pa.us wrote: [ man, this thread has totally outlived its title, could we change that? ?I'll start with this subtopic ] Robert Haas robertmh...@gmail.com writes: In fact,

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 peter.geoghega...@gmail.com wrote: I'm investigating the possibility of developing a utility function for our C++ client library, libpqxx, that produces array literals that can

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 Moncuremmonc...@gmail.com wrote: You can send nested arrays safely. You just have to be very formal about escaping *everything* both as you get it

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 br...@momjian.us wrote: It seems LIKE is considering the trailing CHAR(10) field spaces as significant, even though our documentations says: -- snip -- It

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 List of

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 thansortingon one column?

On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote: - Original Message - From: Kenneth Marshall k...@rice.edu To: Li Jie jay23j...@gmail.com Cc: pgsql-hackers pgsql-hackers@postgresql.org Sent: Thursday, December 23, 2010 10:30 PM Subject: Re: [HACKERS] Why is sorting on two

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 to...@mudrunka.cz napsal(a): Thx for you answers :-) Well... i know that i can write my own plugin and i am familiar with C so this is

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

On Mon, Dec 20, 2010 at 02:10:39PM -0500, Tom Lane wrote: David Fetter da...@fetter.org 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.

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

On Mon, Dec 20, 2010 at 03:08:48PM -0500, Tom Lane wrote: Kenneth Marshall k...@rice.edu 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 leave them out? It's not like

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 09:39:12AM -0500, Tom Lane wrote: Magnus Hagander mag...@hagander.net 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

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 actually

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 m...@msys.ch wrote: Am 06.12.10 15:37, schrieb Merlin Moncure: On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote: On Sun, Dec 5, 2010 at 10:22, Marc Balmer

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 bit of

Re: [HACKERS] unlogged tables

On Wed, Nov 17, 2010 at 02:16:06PM -0500, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert is probably going to object that he wanted to prevent any fsyncing for unlogged tables, but the discussion over in

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 gsst...@mit.edu wrote: On Tue, Nov 9, 2010 at 5:06 PM, Aidan Van Dyk ai...@highrise.ca wrote: So, for getting checksums, we have to offer up a few things: 1) zero-copy writes, we need to

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 nicolas.barb...@gmail.com wrote: 2010/11/2 Kenneth Marshall k...@rice.edu: Given that our hash implimentation mixes the input data well (It does. I tested it.) then a simple rotate

Re: [HACKERS] Hash support for arrays

On Wed, Nov 03, 2010 at 10:24:16AM +0100, Nicolas Barbier wrote: 2010/11/2 Kenneth Marshall k...@rice.edu: 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 maintain all of the needed

Re: [HACKERS] Hash support for arrays

On Tue, Nov 02, 2010 at 04:42:19PM -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote: Really? ?I think I don't understand when this fails isn't obviously better than being able to predict when it fails ...

Re: [HACKERS] PostgreSQL and HugePage

On Wed, Oct 20, 2010 at 10:10:00AM -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Oct 19, 2010 at 11:30 PM, daveg da...@sonic.net wrote: On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote: Heh - provided you specify SHM_HUGETLB in the relevant call

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 documents

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 git

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 j...@agliodbs.com 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

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 stupid as

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 ste...@kaltenbrunner.cc wrote: On 05/19/2010 08:13 AM, Tom Lane wrote: Bernd Helmle maili...@oopsware.de writes: --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh jes...@krogh.cc

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 jes...@krogh.cc 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

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

[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

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: http://search.cpan.org/~timb/PostgreSQL-PLPerl-Injector-1.002/lib/PostgreSQL/PLPerl/Injector.pm I'm wondering if we can reasonably continue to support plperl as a trusted language, or

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 environments, then

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 and...@dunslane.net writes: Emmanuel

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 ha...@2ndquadrant.com 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

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, assuming

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 laurenz.a...@wien.gv.at 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] Rejecting weak passwords

On Thu, Oct 01, 2009 at 01:07:04PM -0400, Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote: I agree with the subsequent comments suggesting a sample module that actually does something useful --- although if it's

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 mark.cave-ayl...@siriusit.co.uk 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

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] 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 returned the correct results. select

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: We have two points with a finite

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 Lanet...@sss.pgh.pa.us 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

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 and...@anarazel.de writes: The default settings currently make it relatively hard to trigger geqo at all. Yes, and that was intentional. One of the

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 temporary

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 this patch? http://archives.postgresql.org

Re: [HACKERS] *_collapse_limit, geqo_threshold

On Sat, Jul 11, 2009 at 12:23:59PM -0400, Tom Lane wrote: Andres Freund and...@anarazel.de 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

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

Re: [HACKERS] *_collapse_limit, geqo_threshold

On Wed, Jul 08, 2009 at 04:13:11PM -0500, Kevin Grittner wrote: Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] *_collapse_limit, geqo_threshold

On Wed, Jul 08, 2009 at 05:46:02PM -0400, Tom Lane wrote: Kevin Grittner kevin.gritt...@wicourts.gov 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

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 k...@rice.edu wrote: What is not clear from Stefen's function listing is how the 8.4 server

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

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

On Thu, Jun 18, 2009 at 05:20:08PM -0400, Tom Lane wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc 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

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 sushant...@gmail.com 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

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

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 k...@rice.edu wrote: On Mon, Jun 01, 2009 at 08:22:23PM -0500, Kevin Grittner wrote: Sushant Sinha sushant...@gmail.com wrote: I

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 helps to

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 heikki.linnakan...@enterprisedb.com wrote: Robert Haas wrote: While investigating some performance problems recently I've had cause to think about the way PostgreSQL uses hash

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 s...@samason.me.uk 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

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 function gensql { echo INSERT INTO bm (c,v

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 pg, so

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 jonah.har...@gmail.comwrote: 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] 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

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 segmentation

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 be the same. Does it still

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 honest

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 pete...@gmx.net 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

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 module

Re: [HACKERS] note 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] note 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 04. 02. 2009 v 13:57 -0600: I

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 conversion. It works for

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 pg...@j-davis.com 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

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 shell in any

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

On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote: Jeff Davis pg...@j-davis.com 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

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 variances. The most definitive benchmark

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 pg...@j-davis.com 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%

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

On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote: Tom Lane t...@sss.pgh.pa.us writes: Jeff Davis pg...@j-davis.com 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

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. Hi Ken, A few comments: 1. New patch

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; val

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:42:41PM -0500, Jaime Casanova wrote: On Wed, Dec 17, 2008 at 4:26 PM, Simon Riggs si...@2ndquadrant.com 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

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 for which it is preferred (large

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 k...@rice.edu wrote: Rebuilding a hash index for the case for which it is preferred (large, large tables) would be excrutiating. there's such a situation? As of 8.4, yes

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 k...@rice.edu wrote: Rebuilding a hash index for the case for which it is preferred (large, large tables

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 Linnakangas

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] 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 -- Server settings

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? % show lc_collate; FWIW, I just ran

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

[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

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 make;make install completed without errors

  1   2   3   >