Re: [PERFORM] postgresql tuning with perf

> On Oct 23, 2017, at 12:19 PM, Purav Chovatia wrote: > > Hello Experts, > > We are trying to tune our postgresql DB using perf. We are running a C > program that connects to postgres DB and calls very simple StoredProcs, one > each for SELECT, INSERT & UPDATE. > > The SPs are very simple.

Re: [PERFORM] Fastest Backup & Restore for perf testing

> On May 27, 2015, at 1:24 PM, Wes Vaske (wvaske) wrote: > > Hi, > > I’m running performance tests against a PostgreSQL database (9.4) with > various hardware configurations and a couple different benchmarks (TPC-C & > TPC-H). > > I’m currently using pg_dump and pg_restore to refresh my da

Re: [PERFORM] IP addresses, NetBlocks, and ASNs

On Apr 19, 2014, at 7:12 PM, Gary Warner wrote: > Does anyone have some good tricks for mapping IP addresses to ASN numbers in > very large volumes? > > This is probably more a "how would you approach this problem?" than "can you > help me tweak this query" > > I have a very large number of

Re: [PERFORM] Issues with OSX and SHMMAX?

On Apr 22, 2013, at 11:19 AM, Josh Berkus wrote: > On 04/21/2013 02:33 PM, Evgeny Shishkin wrote: >> >> On Apr 22, 2013, at 1:29 AM, Josh Berkus wrote: >> >>> Folks, >>> >>> I've heard a rumor that the most recent update of OSX "mountain lion" >>> lowers the installed SHMMAX to 4MB, which pr

Re: [PERFORM] Savepoints in transactions for speed?

On Nov 27, 2012, at 2:04 PM, Mike Blackwell wrote: > I need to delete about 1.5 million records from a table and reload it in one > transaction. The usual advice when loading with inserts seems to be group > them into transactions of around 1k records. Committing at that point would > leave

Re: [PERFORM] anyone tried to use hoard allocator?

On Mar 26, 2012, at 2:50 AM, Tomas Vondra wrote: > Hi all, > > today I've noticed this link on HN: http://plasma.cs.umass.edu/emery/hoard > > Seems like an interesting option for systems with a lot of CPUs that are > doing a lot of alloc operations. Right now I don't have a suitable system > to

Re: [PERFORM] index usage for min() vs. "order by asc limit 1"

On Nov 17, 2011, at 5:12 PM, Ben Chobot wrote: > I have two queries in PG 9.1. One uses an index like I would like, the other > does not. Is this expected behavior? If so, is there any way around it? I don't think you want the group by in that first query. Cheers, Steve > > > postgres=#

Re: [PERFORM] Request for feedback on hardware for a new database server

On Mar 17, 2011, at 5:51 PM, Oliver Charles wrote: > Hello, > > At MusicBrainz we're looking to get a new database server, and are > hoping to buy this in the next couple of days. I'm mostly a software > guy, but I'm posting this on behalf of Rob, who's actually going to be > buying the hardware

Re: [PERFORM] big joins not converging

On Mar 10, 2011, at 1:25 PM, Dan Ancona wrote: > Hi postgressers - > > As part of my work with voter file data, I pretty regularly have to join one > large-ish (over 500k rows) table to another. Sometimes this is via a text > field (countyname) + integer (voter id). I've noticed sometimes this

Re: [PERFORM] How to boost performance of queries containing pattern matching characters

On Feb 14, 2011, at 12:09 AM, Artur Zając wrote: >> Looks like you've almost re-invented the trigram module: >> http://www.postgresql.org/docs/9.0/static/pgtrgm.html > > I didn't know about this module. > Idea to use three letters strings and use Full Text Search is the same, but > the rest is

Re: [PERFORM] Using more tha one index per table

On Jul 21, 2010, at 7:27 PM, Greg Smith wrote: > Steve Atkins wrote: >> If http://postgresql.org/docs/9.0/* were to 302 redirect to >> http://postgresql.org/docs/current/* while 9.0 is the current release (and >> similarly for 9.1 and so on) I suspect we'd find

Re: [PERFORM] Using more tha one index per table

On Jul 21, 2010, at 6:47 PM, Greg Smith wrote: > Craig James wrote: >> By using "current" and encouraging people to link to that, we could quickly >> change the Google pagerank so that a search for Postgres would turn up the >> most-recent version of documentation. > > How do you propose to en

Re: [PERFORM] select on 22 GB table causes "An I/O error occured while sending to the backend." exception

On Aug 28, 2008, at 6:26 AM, Matthew Wakeling wrote: On Wed, 27 Aug 2008, [EMAIL PROTECTED] wrote: if memory overcommit is disabled, the kernel checks to see if you have an extra 1G of ram available, if you do it allows the process to continue, if you don't it tries to free memory (by throw

Re: [PERFORM] Using PK value as a String

On Aug 12, 2008, at 8:21 AM, Bill Moran wrote: In response to Moritz Onken <[EMAIL PROTECTED]>: Am 12.08.2008 um 17:04 schrieb Bill Moran: In response to Moritz Onken <[EMAIL PROTECTED]>: We chose UUID as PK because there is still some information in an integer key. You can see if a user

Re: [PERFORM] Mailing list hacked by spammer?

On Jul 18, 2008, at 4:02 PM, Craig James wrote: I've never gotten a single spam from the Postgres mailing list ... until today. A Chinese company selling consumer products is using this list. I have my filters set to automatically trust this list because it has been so reliable until now

Re: [PERFORM] What constitutes a complex query

On May 6, 2008, at 8:45 AM, Justin wrote: This falls under the stupid question and i'm just curious what other people think what makes a query complex? If I know in advance exactly how the planner will plan the query (and be right), it's a simple query. Otherwise it's a complex query. A

Re: [PERFORM] Best way to index IP data?

On Jan 11, 2008, at 3:52 PM, Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 11 Jan 2008 15:37:37 -0800 Steve Atkins <[EMAIL PROTECTED]> wrote: Well, maybe. The problem is actually that, without a netmask under CIDR, the address alone isn't really e

Re: [PERFORM] Best way to index IP data?

On Jan 11, 2008, at 3:00 PM, Andrew Sullivan wrote: On Fri, Jan 11, 2008 at 02:38:27PM -0800, Steve Atkins wrote: I don't think there's ambiguity about what an dotted-quad without a netmask means, and hasn't been for a long time. Am I missing something? Well, maybe. The prob

Re: [PERFORM] Best way to index IP data?

On Jan 11, 2008, at 2:24 PM, Andrew Sullivan wrote: On Fri, Jan 11, 2008 at 05:02:36PM -0500, Michael Stone wrote: networks), but there's a conspicuous lack of a type for (hosts). I suppose if you really are sure that you want to store hosts and not networks Well, part of the trouble is tha

Re: [PERFORM] Best way to index IP data?

On Jan 11, 2008, at 7:19 AM, Tom Lane wrote: Pomarede Nicolas <[EMAIL PROTECTED]> writes: As ip4r seems to work very well with postgresql, is there a possibility to see it merged in postgresql, to have a native 4 bytes IPv4 address date type ? Given that the world is going to IPv6 in a f

Re: [PERFORM] Best way to index IP data?

On Jan 10, 2008, at 3:14 PM, Kevin Kempter wrote: Hi List; We'll be loading a table with begining & ending I.P.'s - the table will likely have upwards of 30million rows. Any thoughts on how to get the best performance out of queries that want to look for IP ranges or the use of between

Re: [PERFORM] Transaction Log

On Aug 29, 2007, at 12:54 PM, Mark Mielke wrote: [EMAIL PROTECTED] wrote: For best performance, the transaction log should be on a separate disk. Does the writing of the log benefit from a battery backed controller as well? If not, what do people think about writing the transaction log

Re: [PERFORM] PITR Backups

On Jun 21, 2007, at 7:30 PM, Toru SHIMOGAKI wrote: Tom Lane wrote: Dan Gorman <[EMAIL PROTECTED]> writes: All of our databases are on NetApp storage and I have been looking at SnapMirror (PITR RO copy ) and FlexClone (near instant RW volume replica) for backing up our databases. The pro

Re: [PERFORM] Volunteer to build a configuration tool

On Jun 18, 2007, at 4:09 PM, [EMAIL PROTECTED] wrote: one thing to point out to people about this idea is that nothing says that this page needs to be served via a webserver. If all the calculations are done in javascript this could be a local file that you open with a browser. do any of

Re: [PERFORM] Best OS for Postgres 8.2

On May 7, 2007, at 2:55 PM, David Levy wrote: Hi, I am about to order a new server for my Postgres cluster. I will probably get a Dual Xeon Quad Core instead of my current Dual Xeon. Which OS would you recommend to optimize Postgres behaviour (i/o access, multithreading, etc) ? I am hesitatin

Re: [PERFORM] Performance of count(*)

On Mar 22, 2007, at 11:26 AM, Guido Neitzer wrote: On 22.03.2007, at 11:53, Steve Atkins wrote: As long as you're ordering by some row in the table then you can do that in straight SQL. select a, b, ts from foo where (stuff) and foo > X order by foo limit 10 Then, record

Re: [PERFORM] Performance of count(*)

On Mar 22, 2007, at 10:21 AM, Craig A. James wrote: Tino Wildenhain wrote: Craig A. James schrieb: ... In our case (for a variety of reasons, but this one is critical), we actually can't use Postgres indexing at all -- we wrote an entirely separate indexing system for our data... ...Ther

Re: [PERFORM] Dispatch-Merge pattern

On Mar 13, 2007, at 6:36 AM, James Riordan wrote: Howdy- I am currently using PostgreSQL to store and process a high-bandwidth event stream. I do not need old events but the delete and vacuum does not terminate due to the large number of events being inserted (it just pushes me over the tippi

Re: [PERFORM] Bad iostat numbers

On Dec 5, 2006, at 8:54 PM, Greg Smith wrote: On Tue, 5 Dec 2006, Craig A. James wrote: I'm not familiar with the inner details of software RAID, but the only circumstance I can see where things would get corrupted is if the RAID driver writes a LOT of blocks to one disk of the array bef

Re: [PERFORM] availability of SATA vendors

On Nov 17, 2006, at 9:45 AM, Jeff Frost wrote: I see many of you folks singing the praises of the Areca and 3ware SATA controllers, but I've been trying to price some systems and am having trouble finding a vendor who ships these controllers with their systems. Are you rolling your own wh

Re: [PERFORM] Unsubscribe

On Oct 4, 2006, at 9:00 AM, Joshua D. Drake wrote: I also don't care about that argument in this situation. People ignorantly posting an unsubscribe to the list get this kind of response because it's an annoyance to the list users, Over time especially now, we will see many more "users"

Re: [PERFORM] Performace Optimization for Dummies

On Sep 28, 2006, at 12:10 PM, Carlo Stonebanks wrote: Are you wrapping all this in a transaction? Yes, the transactions can typically wrap 1 to 10 single-table, single-row inserts and updates. You're doing some dynamically generated selects as part of the "de-duping" process? They're

Re: [PERFORM] Performace Optimization for Dummies

On Sep 28, 2006, at 10:53 AM, Carlo Stonebanks wrote: are you using the 'copy' interface? Straightforward inserts - the import data has to transformed, normalised and de-duped by the import program. I imagine the copy interface is for more straightforward data importing. These are - buy

Re: [PERFORM] Hardware upgraded but performance still ain't good

On Aug 9, 2006, at 5:47 AM, Joshua D. Drake wrote: Alex Turner wrote: First off - very few third party tools support debian. Debian is a sure fire way to have an unsupported system. Use RedHat or SuSe (flame me all you want, it doesn't make it less true). *cough* BS *cough* Linux is L

Re: [PERFORM] most bang for buck with ~ $20,000

On Aug 8, 2006, at 1:43 PM, Kenji Morishige wrote: I am considering a setup such as this: - At least dual cpu (possibly with 2 cores each) - 4GB of RAM - 2 disk RAID 1 array for root disk - 4 disk RAID 1+0 array for PGDATA - 2 disk RAID 1 array for pg_xlog Does anyone know a vendor

Re: [PERFORM] Partitioned tables in queries

On Jul 21, 2006, at 12:17 PM, Kevin Keith wrote: I have a case where I am partitioning tables based on a date range in version 8.1.4. For example: table_with_millions_of_records interaction_id char(16) primary key start_date timestamp (without timezone) - indexed .. other columns child_1

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

On Jun 12, 2006, at 6:15 PM, Joshua D. Drake wrote: Empirically... postgresql built for 64 bits is marginally slower than that built for a 32 bit api on sparc. None of my customers have found 64 bit x86 systems to be suitable for production use, yet, so I've not tested on any of those ar

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

On Jun 12, 2006, at 3:28 PM, Anthony Presley wrote: Hi all! I had an interesting discussion today w/ an Enterprise DB developer and sales person, and was told, twice, that the 64-bit linux version of Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1) is SIGNIFICANTLY SLO

Re: [PERFORM] [GENERAL] Arguments Pro/Contra Software Raid

On May 9, 2006, at 11:26 AM, Joshua D. Drake wrote: You're not suggesting that a hardware RAID controller will protect you against drives that lie about sync, are you? Of course not, but which drives lie about sync that are SATA? Or more specifically SATA-II? SATA-II, none that I'm awar

Re: [PERFORM] [GENERAL] Arguments Pro/Contra Software Raid

On May 9, 2006, at 8:51 AM, Joshua D. Drake wrote: ("Using SATA drives is always a bit of risk, as some drives are lying about whether they are caching or not.") Don't buy those drives. That's unrelated to whether you use hardware or software RAID. Sorry that is an extremely misleading st

Re: [PERFORM] [GENERAL] Arguments Pro/Contra Software Raid

On May 9, 2006, at 2:16 AM, Hannes Dorbath wrote: Hi, I've just had some discussion with colleagues regarding the usage of hardware or software raid 1/10 for our linux based database servers. I myself can't see much reason to spend $500 on high end controller cards for a simple Raid 1.

Re: [PERFORM] ip address data type

On Apr 24, 2006, at 3:45 PM, Sriram Dandapani wrote: Hi I have queries that use like operators and regex patterns to determine if an ip address is internal or external (this is against a table with say 100 million distinct ip addresses). Does the inet data type offer comparison/searc

Re: [PERFORM] Background writer configuration

On Mar 17, 2006, at 4:24 AM, Evgeny Gridasov wrote: Yesterday we recieved a new server 2xAMD64(2core x 2chips = 4 cores) 8GB RAM and RAID-1 (LSI megaraid) I've maid some tests with pgbench (scaling 1000, database size ~ 16Gb) First of all, I'd like to mention that it was strange to see that th

Re: [PERFORM] Best way to get all different values in a column

On Fri, Oct 14, 2005 at 06:02:56PM +0200, [EMAIL PROTECTED] wrote: > Ok, since my question got no answer on the general list, I'm reposting > it here since this list seems in fact better suited to it. > > Does anyone here know what is the most efficient way to list all > different values of a

Re: [PERFORM] Is There Any Way ....

On Tue, Oct 04, 2005 at 11:06:54PM -0400, Ron Peacetree wrote: > Some might even argue that IBM (where Codd and Date worked) > and Oracle just _might_ have had justification for the huge effort > they put into developing such infrastructure. The OS and FS world is very, very different now than i

Re: [PERFORM] Alternative to a temporary table

On Mon, Oct 03, 2005 at 11:47:52AM -0400, Steven Rosenstein wrote: > I currently create a temporary table to hold the selected server_id's and > characteristics. I then join this temp table with other data tables to > produce my reports. My reason for using the temporary table method is that > t

Re: [PERFORM] How can this be?

On Fri, Sep 16, 2005 at 08:34:14PM -0500, Martin Nickel wrote: > Hello all, > Mostly Postgres makes sense to me. But now and then it does something > that boggles my brain. Take the statements below. I have a table > (agent) with 5300 rows. The primary key is agent_id. I can do SELECT > agen

Re: [PERFORM] Planner constants for RAM resident databases

On Fri, Jul 01, 2005 at 09:59:38PM -0400, Emil Briggs wrote: > I'm working with an application where the database is entirely resident in > RAM > (the server is a quad opteron with 16GBytes of memory). It's a web > application and handles a high volume of queries. The planner seems to be > gen

Re: [PERFORM] faster search

On Fri, Jun 10, 2005 at 01:45:05PM -0400, Clark Slater wrote: > Hi- > > Would someone please enlighten me as > to why I'm not seeing a faster execution > time on the simple scenario below? Because you need to extract a huge number of rows via a seqscan, sort them and then throw them away, I think

Re: [PERFORM] sequential scan performance

On Sun, May 29, 2005 at 08:27:26AM -0500, Michael Engelhart wrote: > Hi - > > I have a table of about 3 million rows of city "aliases" that I need > to query using LIKE - for example: > > select * from city_alias where city_name like '%FRANCISCO' > > > When I do an EXPLAIN ANALYZE on the abov

Re: [PERFORM] Plan for relatively simple query seems to be very inefficient

On Wed, Apr 06, 2005 at 06:52:35PM +0200, Arjen van der Meijden wrote: > Hi list, > > I noticed on a forum a query taking a surprisingly large amount of time > in MySQL. Of course I wanted to prove PostgreSQL 8.0.1 could do it much > better. To my surprise PostgreSQL was ten times worse on the s

Re: [PERFORM] What needs to be done for real Partitioning?

On Sat, Mar 19, 2005 at 12:02:38PM -0800, Josh Berkus wrote: > Folks, > > I may (or may not) soon have funding for implementing full table partitioning > in PostgreSQL. I thought it would be a good idea to discuss with people here > who are already using pseudo-partitioning what things need to

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

On Fri, Jan 21, 2005 at 04:35:38PM +, Randolf Richardson wrote: > Yes, indeed, that will be. My feeling is that Network Solutions > actually manages the .NET and .COM registries far better than anyone else > does, and when .ORG was switched away I didn't like the lack of flexibility

Re: [PERFORM] Tips for a system with _extremely_ slow IO?

On Fri, Dec 17, 2004 at 11:51:12PM -0800, Ron Mayer wrote: > Any advice for settings for extremely IO constrained systems? > > A demo I've set up for sales seems to be spending much of it's time in > disk wait states. > > > The particular system I'm working with is: >Ext3 on Debian inside M

Re: [PERFORM] how much mem to give postgres?

On Wed, Oct 20, 2004 at 07:16:18PM +0100, Matt Clark wrote: > > > >Hyperthreading is actually an excellent architectural feature that > >can give significant performance gains when implemented well and used > >for an appropriate workload under a decently HT aware OS. > > > >IMO, typical RDBMS strea

Re: [PERFORM] how much mem to give postgres?

On Wed, Oct 20, 2004 at 03:07:00PM +0100, Matt Clark wrote: > You turn it off in the BIOS. There is no 'other half', the processor is > just pretending to have two cores by shuffling registers around, which > gives maybe a 5-10% performance gain in certain multithreaded > situations. > A ha

Re: [PERFORM] Does PostgreSQL run with Oracle?

On Fri, Oct 15, 2004 at 11:54:44AM -0500, [EMAIL PROTECTED] wrote: > My basic question to the community is "is PostgreSQL approximately as fast > as Oracle?" > I'm currently running single processor UltraSPARC workstations, and intend > to use Intel Arch laptops and Linux. The application is a bi

Re: [PERFORM] Performance suggestions for an update-mostly database?

On Mon, Oct 04, 2004 at 10:38:14AM -0700, Josh Berkus wrote: > Steve, > > > I'm used to performance tuning on a select-heavy database, but this > > will have a very different impact on the system. Does anyone have any > > experience with an update heavy system, and have any performance hints > > o

[PERFORM] Performance suggestions for an update-mostly database?

I'm putting together a system where the operation mix is likely to be >95% update, <5% select on primary key. I'm used to performance tuning on a select-heavy database, but this will have a very different impact on the system. Does anyone have any experience with an update heavy system, and have a

Re: [PERFORM] Caching of Queries

On Mon, Sep 27, 2004 at 09:19:12PM +0100, Matt Clark wrote: > >Basically you set a default in seconds for the HTML results to be > >cached, and then have triggers set that force the cache to regenerate > >(whenever CRUD happens to the content, for example). > > > >Can't speak for Perl/Python/Ruby/

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres --

On Wed, Sep 15, 2004 at 11:16:44AM +0200, Markus Schaber wrote: > Hi, > > On Tue, 14 Sep 2004 22:10:04 -0700 > Steve Atkins <[EMAIL PROTECTED]> wrote: > > > > Is there by any chance a set of functions to manage adding and removing > > > partitions? Certain

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables

On Tue, Sep 14, 2004 at 05:33:33PM -0500, Jim C. Nasby wrote: > On Mon, Sep 13, 2004 at 11:07:35PM +0100, Simon Riggs wrote: > > PostgreSQL's functionality is in many ways similar to Oracle Partitioning. > > > > Loading up your data in many similar tables, then creating a view like: > > > > CREAT

Re: [PERFORM] [ADMIN] Raw devices vs. Filesystems

On Wed, Apr 07, 2004 at 09:09:16AM -0700, Josh Berkus wrote: > If your intention in this test is to show the superiority of raw devices, let > me give you a reality check: barring some major corporate backing getting > involved, we can't possibly implement our own PG-FS for database support. We

Re: [PERFORM] [HACKERS] fsync method checking

On Fri, Mar 26, 2004 at 07:25:53AM +0100, Manfred Spraul wrote: > >Compare file sync methods with one 8k write: > > (o_dsync unavailable) > > open o_sync, write 6.270724 > > write, fdatasync13.275225 > > write, fsync, 13.359847 > > > > > Odd. Whic

Re: [PERFORM] optimizing large query with IN (...)

On Wed, Mar 10, 2004 at 02:02:23PM -0300, Marcus Andree S. Magalhaes wrote: > Hmm... from the 'performance' point of view, since the data comes from > a quite complex select statement, Isn't it better/quicker to have this > select replaced by a select into and creating a temporary database? Defin

Re: [PERFORM] optimizing large query with IN (...)

On Wed, Mar 10, 2004 at 12:35:15AM -0300, Marcus Andree S. Magalhaes wrote: > Guys, > > I got a Java program to tune. It connects to a 7.4.1 postgresql server > running Linux using JDBC. > > The program needs to update a counter on a somewhat large number of > rows, about 1200 on a ~130k rows tab

Re: [PERFORM] Slow join using network address function

On Tue, Feb 24, 2004 at 09:14:42AM -0800, Steve Atkins wrote: > On Tue, Feb 24, 2004 at 01:07:10PM +0100, Eric Jain wrote: > > > <http://word-to-the-wise.com/ipr.tgz> is a datatype that contains > > > a range of IPv4 addresses, and which has the various operators to &

Re: [PERFORM] Slow join using network address function

On Tue, Feb 24, 2004 at 01:07:10PM +0100, Eric Jain wrote: > > is a datatype that contains > > a range of IPv4 addresses, and which has the various operators to > > make it GIST indexable. > > Great, this looks very promising. > > > No cast operators betw

Re: [PERFORM] Slow join using network address function

On Tue, Feb 24, 2004 at 10:23:22AM -0500, Tom Lane wrote: > "Eric Jain" <[EMAIL PROTECTED]> writes: > >> is a datatype that contains > >> a range of IPv4 addresses, and which has the various operators to > >> make it GIST indexable. > > > Great, this looks v

Re: [PERFORM] Slow join using network address function

amp;&' returns true if two ipr fields intersect. Bugs include: 0.0.0.0/0 doesn't do what it should on input. No documentation. No cast operators between ipr and inet types. No documentation. I was planning on doing some docs before releasing it, but here it is anyway. Cheers, S

Re: [PERFORM] For full text indexing, which is better, tsearch2 or

On Fri, Nov 28, 2003 at 01:18:48PM +0800, Christopher Kings-Lynne wrote: > > >Any thoughts? > > Actually, I ran my tests using tsearch V1. I wonder if there has been > some weird regression between tsearch 1 and 2? Maybe. tsearch2 doesn't seem production ready in other respects (untsearch2.sql

Re: [PERFORM] For full text indexing, which is better, tsearch2 or

On Wed, Nov 26, 2003 at 09:12:30PM -0800, Steve Atkins wrote: > On Thu, Nov 27, 2003 at 12:41:59PM +0800, Christopher Kings-Lynne wrote: > > >Does anyone have any metrics on how fast tsearch2 actually is? > > > > > >I tried it on a synthetic dataset of a million doc

Re: [PERFORM] For full text indexing, which is better, tsearch2 or

On Thu, Nov 27, 2003 at 12:41:59PM +0800, Christopher Kings-Lynne wrote: > >Does anyone have any metrics on how fast tsearch2 actually is? > > > >I tried it on a synthetic dataset of a million documents of a hundred > >words each and while insertions were impressively fast I gave up on > >the searc

Re: [PERFORM] For full text indexing, which is better, tsearch2 or

On Thu, Nov 27, 2003 at 08:51:14AM +0800, Christopher Kings-Lynne wrote: > >Which one is better (performance/easier to use), > >tsearch2 or fulltextindex? > >there is an example how to use fulltextindex in the > >techdocs, but I checked the contrib/fulltextindex > >package, there is a WARNING that