Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Hey Tom, On 11/8/17, 4:39 PM, "Tom Lane" wrote: So now I'm wondering if you know something the rest of us don't about how to configure the platform for bonjour to work. Nope – in fact, I hadn’t tried to use Bonjour on this instance, but had only enabled it thinking

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

# dpkg -S !$ dpkg -S /usr/lib/x86_64-linux-gnu/libdns_sd.so.1.0.0 libavahi-compat-libdnssd1:amd64: /usr/lib/x86_64-linux-gnu/libdns_sd.so.1.0.0 Also:   ii libavahi-compat-libdnssd1:amd640.6.32-1ubuntu1 amd64Avahi Apple Bonjour

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Hi Tom – works for me on Linux (Ubuntu)… - Luke *** /home/llonergan/archive/configure.in2017-11-08 14:17:56.804891827 -0800 --- configure.in2017-11-08 14:15:58.961186149 -0800 *** *** 1293,1298 --- 1293,1299 if test

[HACKERS] Pg V10: Patch for bug in bonjour support

Hi all – I’m doing some geo analysis and was excited to see all the new features in V10 – particularly the declarative partitioning support! Found a tiny bug in the build for Bonjour – patch below: *** configure.in  2017-10-02 14:09:15.0 -0700 ---

Re: [HACKERS] 8.3 / 8.2.6 restore comparison

Bah. It's the stuff in the format translation path and conversion to/from datums that is the bottleneck. We sped up COPY TO recently by a factor of 10 using similar approaches to what we did for COPY FROM in the past. There's a format conversion that is the culprit. We routinely get about 12

Re: [HACKERS] How to keep a table in memory?

Vacuum is a better thing to run, much less CPU usage. - Luke Msg is shrt cuz m on ma treo -Original Message- From: Greg Smith [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 11:59 PM Eastern Standard Time To: Alex Drobychev Cc: pgsql-hackers@postgresql.org

Re: [HACKERS] Including Snapshot Info with Indexes

Hi Hannu, On 10/14/07 12:58 AM, Hannu Krosing [EMAIL PROTECTED] wrote: What has happened in reality, is that the speed difference between CPU, RAM and disk speeds has _increased_ tremendously Yes. which makes it even more important to _decrease_ the size of stored data if you want good

Re: [HACKERS] top for postgresql (ptop?)

Hi Mark, I haven't yet looked at what you've done, but I'm an enthusiastic supporter of this idea. We're looking to do something that will view running queries and allow drill down into those executing at any given time, showing their plans and some notion of what operators are being executed.

Re: [HACKERS] top for postgresql (ptop?)

Hi Greg, On 9/25/07 9:15 PM, Greg Smith [EMAIL PROTECTED] wrote: It's also worth noting that there's a similar Linux utility called gstack. Cool! So - the basic idea is that we could uncover the current run context in a very lightweight manner by just dumping the stack and interpreting it.

Re: [HACKERS] Raw device I/O for large objects

Index organized tables would do this and it would be a generic capability. - Luke Msg is shrt cuz m on ma treo -Original Message- From: Georgi Chulkov [mailto:[EMAIL PROTECTED] Sent: Monday, September 17, 2007 11:50 PM Eastern Standard Time To: Tom Lane Cc:

[HACKERS] FW: was [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1

Below is a patch against Greenplum Database that fixes the problem. - Luke -- Forwarded Message From: Luke Lonergan [EMAIL PROTECTED] Date: Fri, 24 Aug 2007 09:25:53 -0700 To: Heikki Linnakangas [EMAIL PROTECTED], Anton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Conversation: [PERFORM

Re: [HACKERS] tsearch2 in PostgreSQL 8.3?

All - we have customers who very much want tsearch2 and will benefit from its inclusion in core. We are also struggling with the update trigger approach for various reasons. Is there a good alternative? Can we embed tsvector updates into the core code efficiently? - Luke Msg is shrt cuz m

Re: [HACKERS] Another idea for index-only scans

A hybrid scan approach combined with this idea would fit nicely - provide results for tids that are directly visible and set a bit in a bitmap for those that need recheck and extend recheck to take a bitmap (wait - it already does :-) - Luke Msg is shrt cuz m on ma treo -Original

Re: [HACKERS] Seq scans roadmap

Hi Jeff, On 5/16/07 4:56 PM, Jeff Davis [EMAIL PROTECTED] wrote: The main benefit of a sync scan will be the ability to start the scan where other scans have already filled the I/O cache with useful blocks. This will require some knowledge of the size of the I/O cache by the syncscan logic,

Re: [HACKERS] Seq scans roadmap

-0700, Jeff Davis wrote: On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote: Luke Lonergan wrote: 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? Sounds reasonable. We need to check the effect on the synchronized scans

Re: [HACKERS] Seq scans roadmap

-development Cc: Simon Riggs; Zeugswetter Andreas ADI SD; CK.Tan; Luke Lonergan; Jeff Davis Subject: Re: [HACKERS] Seq scans roadmap Just to keep you guys informed, I've been busy testing and pondering over different buffer ring strategies for vacuum, seqscans and copy. Here's what I'm going

Re: [HACKERS] Seq scans roadmap

Hi Simon, On 5/12/07 12:35 AM, Simon Riggs [EMAIL PROTECTED] wrote: I'm slightly worried that the results for COPY aren't anywhere near as good as the SELECT and VACUUM results. It isn't clear from those numbers that the benefit really is significant. COPY is bottlenecked on datum formation

Re: [HACKERS] Seq scans roadmap

Heikki, On 3A: In practice, the popular modern OS'es (BSD/Linux/Solaris/etc) implement dynamic I/O caching. The experiments have shown that benefit of re-using PG buffer cache on large sequential scans is vanishingly small when the buffer cache size is small compared to the system memory. Since

Re: [HACKERS] Seq scans roadmap

Heikki, That's interesting. Care to share the results of the experiments you ran? I was thinking of running tests of my own with varying table sizes. Yah - it may take a while - you might get there faster. There are some interesting effects to look at between I/O cache performance and PG

Re: [HACKERS] TOASTing smaller things

Hi Bruce, On 4/12/07 9:24 AM, Bruce Momjian [EMAIL PROTECTED] wrote: Luke Lonergan wrote: Hi Bruce, How about these: - Allow specification of TOAST size threshold in bytes on a per column basis - Enable storage of columns in separate TOAST tables - Enable use of multi-row compression

Re: [HACKERS] TOASTing smaller things

: Luke Lonergan wrote: I advocate the following: - Enable specification of TOAST policy on a per column basis As a first step, then: - Enable vertical partitioning of tables using per-column specification of storage policy. How are these different from ALTER TABLE SET STORAGE? They need

Re: [HACKERS] Modifying TOAST thresholds

Not just EDB :-) - Luke Msg is shrt cuz m on ma treo -Original Message- From: Chris Browne [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 10:07 PM Eastern Standard Time To: pgsql-hackers@postgresql.org Subject:Re: [HACKERS] Modifying TOAST thresholds [EMAIL

Re: [HACKERS] Modifying TOAST thresholds

Tom, On 4/3/07 7:15 AM, Tom Lane [EMAIL PROTECTED] wrote: BTW, it strikes me that a GUC variable is quite the wrong way to go about this. The right way is a table storage parameter, a la FILLFACTOR, so that it can be set on a per-table basis. That would also give us a chance to fix my

Re: [HACKERS] Oracle indemnifies PostgreSQL on its patents

Josh, On 3/31/07 11:01 AM, Joshua D. Drake [EMAIL PROTECTED] wrote: The PostgreSQL project should not give any credence to these announcements and should avoid all patent issues possible. I think that's appropriate - the structure of the OIN looks like it's: 1) focused on Linux 2) designed to

Re: [HACKERS] Synchronized Scan benchmark results

Jeff, Your conclusions sound great - can you perhaps put the timings in a column in your table so we can confirm them? - Luke On 4/2/07 4:14 PM, Jeff Davis [EMAIL PROTECTED] wrote: I posted some fairly detailed benchmark results for my Synchronized Scan patch and it's interactions with

Re: [HACKERS] Oracle indemnifies PostgreSQL on its patents

Bruce, This is big news - has anyone checked to see if the agreement for the OIN is in perpetuity? Or is their agreement to not pursue patents only for as long as they are members? - Luke On 3/30/07 10:43 AM, Bruce Momjian [EMAIL PROTECTED] wrote: Here is a surprising article about how

Re: [HACKERS] Oracle indemnifies PostgreSQL on its patents

: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 02:55 PM Eastern Standard Time To: Alvaro Herrera Cc: Luke Lonergan; Bruce Momjian; PostgreSQL-development Subject:Re: [HACKERS] Oracle indemnifies PostgreSQL on its patents Alvaro Herrera [EMAIL PROTECTED

Re: [HACKERS] TOASTing smaller things

I advocate the following: - Enable specification of TOAST policy on a per column basis As a first step, then: - Enable vertical partitioning of tables using per-column specification of storage policy. - Luke On 3/21/07 1:12 PM, Bruce Momjian [EMAIL PROTECTED] wrote: Is this a TODO?

Re: [HACKERS] TOASTing smaller things

Andreas, On 3/22/07 9:40 AM, Andreas Pflug [EMAIL PROTECTED] wrote: Wouldn't it be enough to enable having the toast table on a different table space? Yes, but the ultimate goal would allow the allocation of a storage mechanism that is unique to each column. The most frequently used

Re: [HACKERS] TOASTing smaller things

Chris, Hmm. Are you trying to do something sort of like CStore? http://db.csail.mit.edu/projects/cstore/ That seems to have some relevant ideas... I think something like is a good way to put it. As you know Cstore was a prototype for Vertica and these are in the same class as SybaseIQ

Re: [HACKERS] TOASTing smaller things

Hi Hannu, On 3/22/07 3:21 PM, Hannu Krosing [EMAIL PROTECTED] wrote: Maybe monetdb ( http://monetdb.cwi.nl/ ) can be of some inspiration ? btw, it may be a good idea to have a verion of bizgresMPP which has monetdb as partition db, if monetdb is as efficient as they tell it is . Yep - I've

Re: [HACKERS] [PATCHES] Bitmapscan changes

Wow, nice! Can you tell us: - how big is the table - cardinality of the column - how big is the index in each case - how much memory on the machine - query and explain analyze Thanks! - Luke Msg is shrt cuz m on ma treo -Original Message- From: Grzegorz Jaskiewicz [mailto:[EMAIL

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Simon, On 3/13/07 2:37 AM, Simon Riggs [EMAIL PROTECTED] wrote: We're planning a modification that I think you should consider: when there is a sequential scan of a table larger than the size of shared_buffers, we are allowing the scan to write through the shared_buffers cache. Write? For

Re: [HACKERS] Synchronized Scan update

Simon, On 3/12/07 6:21 AM, Simon Riggs [EMAIL PROTECTED] wrote: So based on those thoughts, sync_scan_offset should be fixed at 16, rather than being variable. In addition, ss_report_loc() should only report its position every 16 blocks, rather than do this every time, which will reduce

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Simon, You may know we've built something similar and have seen similar gains. We're planning a modification that I think you should consider: when there is a sequential scan of a table larger than the size of shared_buffers, we are allowing the scan to write through the shared_buffers cache.

Re: [HACKERS] Auto creation of Partitions

Simon, What happens to the data when the function is dropped or replaced? - Luke Msg is shrt cuz m on ma treo -Original Message- From: Simon Riggs [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 06:20 AM Eastern Standard Time To: NikhilS Cc: Shane Ambler; Luke

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Cool! - Luke Msg is shrt cuz m on ma treo -Original Message- From: Simon Riggs [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 02:32 PM Eastern Standard Time To: Luke Lonergan; ITAGAKI Takahiro Cc: Sherry Moore; Tom Lane; Mark Kirkwood; Pavan Deolasee; Gavin Sherry

Re: [HACKERS] Estimating seq_page_fetch and random_page_fetch

Adding to this: Ayush recently wrote a C program that emulates PG IO to do this analysis, and we came out with (predictably) a ratio of sequential/random of 20-50 (for a single user). This is predictable because the random component is fixed at the access time of a single hard drive no matter

Re: [HACKERS] Grouped Index Tuples / Clustered Indexes

+1 On 3/7/07 6:53 AM, Grzegorz Jaskiewicz [EMAIL PROTECTED] wrote: my only question would be. Why isn't that in core already ? ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an

Re: [HACKERS] Auto creation of Partitions

Simon, On 3/7/07 5:26 AM, Simon Riggs [EMAIL PROTECTED] wrote: What is really needed is a data structure that allows range partitions to be accessed more efficiently. This could make adding partitions and deciding in which partition a specific value goes an O(logN) operation. I think we need

Re: [HACKERS] Time-correlated columns in large tables

Jeroen, On 3/5/07 12:39 PM, Jeroen T. Vermeulen [EMAIL PROTECTED] wrote: I guess if you did simple run-length compression on these bitmaps you'd end up more or less where I came in. But you wouldn't want to flip a bit somewhere in the middle of a compressed data stream, of course. :- We

Re: [HACKERS] PostgreSQL - 'SKYLINE OF' clause added!

Yep - we're paying attention Josh! I like the category being explored with skyline, I'm not sure yet how it fits with existing 'soft data' models and applications that use them. If SKYLINE is interesting to app developers, maybe we should consider it for Bizgres? - Luke Msg is shrt cuz m on

Re: [HACKERS] Auto creation of Partitions

Andreas, On 3/7/07 11:45 AM, Zeugswetter Andreas ADI SD [EMAIL PROTECTED] wrote: Whoa, do you have anything to back that up ? Sure - when we start to consider designs that implement advanced data management features, we run into problems with the architecture of tables-tables-tables Here

Re: [HACKERS] Bug: Buffer cache is not scan resistant

) at the higher data rates due to this effect. - Luke Msg is shrt cuz m on ma treo -Original Message- From: Sherry Moore [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 10:05 PM Eastern Standard Time To: Simon Riggs Cc: Sherry Moore; Tom Lane; Luke Lonergan; Mark Kirkwood

Re: [HACKERS] Bug: Buffer cache is not scan resistant

So either way, it isn't in processor cache after the read. So how can there be any performance benefit? It's the copy from kernel IO cache to the buffer cache that is L2 sensitive. When the shared buffer cache is polluted, it thrashes the L2 cache. When the number of pages being written to

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Hi Tom, Now this may only prove that the disk subsystem on this machine is too cheap to let the system show any CPU-related issues. Try it with a warm IO cache. As I posted before, we see double the performance of a VACUUM from a table in IO cache when the shared buffer cache isn't being

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Hi Tom, Even granting that your conclusions are accurate, we are not in the business of optimizing Postgres for a single CPU architecture. I think you're missing my/our point: The Postgres shared buffer cache algorithm appears to have a bug. When there is a sequential scan the blocks are

Re: [HACKERS] Bug: Buffer cache is not scan resistant

The Postgres shared buffer cache algorithm appears to have a bug. When there is a sequential scan the blocks are filling the entire shared buffer cache. This should be fixed. No, this is not a bug; it is operating as designed. The point of the current bufmgr algorithm is to

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Hi Mark, lineitem has 1535724 pages (11997 MB) Shared Buffers Elapsed IO rate (from vmstat) -- --- - 400MB 101 s122 MB/s 2MB 100 s 1MB 97 s 768KB93 s 512KB86 s 256KB77 s

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Hi Tom, On 3/5/07 8:53 AM, Tom Lane [EMAIL PROTECTED] wrote: Hm, that seems to blow the it's an L2 cache effect theory out of the water. If it were a cache effect then there should be a performance cliff at the point where the cache size is exceeded. I see no such cliff, in fact the middle

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Tom, On 3/5/07 8:53 AM, Tom Lane [EMAIL PROTECTED] wrote: Hm, that seems to blow the it's an L2 cache effect theory out of the water. If it were a cache effect then there should be a performance cliff at the point where the cache size is exceeded. I see no such cliff, in fact the middle

Re: [HACKERS] Bug: Buffer cache is not scan resistant

5.834.10 28016 6.114.46 WRT what you found on the selection algorithm, it might also explain the L2 effects I think. I'm also still of the opinion that polluting the shared buffer cache for a seq scan does not make sense. - Luke On 3/5/07 10:21 AM, Luke Lonergan

Re: [HACKERS] Bug: Buffer cache is not scan resistant

This sounds like a good idea. - Luke Msg is shrt cuz m on ma treo -Original Message- From: Simon Riggs [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 02:37 PM Eastern Standard Time To: Josh Berkus; Tom Lane; Pavan Deolasee; Mark Kirkwood; Gavin Sherry; Luke Lonergan

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Deolasee; Gavin Sherry; Luke Lonergan; PGSQL Hackers; Doug Rady; Sherry Moore Subject:Re: [HACKERS] Bug: Buffer cache is not scan resistant Mark Kirkwood [EMAIL PROTECTED] writes: Tom Lane wrote: But what I wanted to see was the curve of elapsed time vs shared_buffers? ... Looks *very

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Tom, On 3/5/07 7:58 PM, Tom Lane [EMAIL PROTECTED] wrote: I looked a bit at the Linux code that's being used here, but it's all x86_64 assembler which is something I've never studied :-(. Here's the C wrapper routine in Solaris:

[HACKERS] Bug: Buffer cache is not scan resistant

I'm putting this out there before we publish a fix so that we can discuss how best to fix it. Doug and Sherry recently found the source of an important performance issue with the Postgres shared buffer cache. The issue is summarized like this: the buffer cache in PGSQL is not scan resistant as

Re: [HACKERS] Bug: Buffer cache is not scan resistant

on ma treo -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Sunday, March 04, 2007 08:36 PM Eastern Standard Time To: Luke Lonergan Cc: PGSQL Hackers; Doug Rady; Sherry Moore Subject:Re: [HACKERS] Bug: Buffer cache is not scan resistant Luke Lonergan

Re: [HACKERS] Bug: Buffer cache is not scan resistant

[mailto:[EMAIL PROTECTED] Sent: Sunday, March 04, 2007 08:36 PM Eastern Standard Time To: Luke Lonergan Cc: PGSQL Hackers; Doug Rady; Sherry Moore Subject:Re: [HACKERS] Bug: Buffer cache is not scan resistant Luke Lonergan [EMAIL PROTECTED] writes: The issue is summarized like

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Gavin, Mark, Could you demonstrate that point by showing us timings for shared_buffers sizes from 512K up to, say, 2 MB? The two numbers you give there might just have to do with managing a large buffer. I suggest two experiments that we've already done: 1) increase shared buffers to

Re: [HACKERS] doxygen.postgresql.org

Yay! This rocks IMO, but I'm a borderline PHB so what do I know ;-) - Luke On 2/6/07 9:19 AM, Magnus Hagander [EMAIL PROTECTED] wrote: http://doxygen.postgresql.org is now set up for your browsing pleasure. It's synced to anoncvs once per day. //Magnus ---(end

Re: [HACKERS] Block B-tree etc. (was Re: Introducing an advanced Frequent

Heikki, On 11/7/06 1:51 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote: I don't think Simon's proposal is meant to address that issue, but did you follow the thread I started in September about Block B-Tree index: http://archives.postgresql.org/pgsql-hackers/2006-09/msg02041.php Aha -

Re: [HACKERS] Introducing an advanced Frequent Update

Simon, Bring it on! We at GP have been evaluating various approaches to index organized tables which unify index with heap storage to solve some of the problems you mention. Split index and heap is a big issue in Postgres and we'd all welcome a good solution to it, even for limited

Re: [HACKERS] Replication documentation addition

Bruce, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Tuesday, October 24, 2006 5:16 PM To: Hannu Krosing Cc: PostgreSQL-documentation; PostgreSQL-development Subject: Re: [HACKERS] Replication documentation addition OK,

Re: [HACKERS] Asynchronous I/O Support

Martijn, On 10/15/06 10:56 AM, Martijn van Oosterhout kleptog@svana.org wrote: Have enough systems actually got to the point of actually supporting async I/O that it's worth implementing? I think there are enough high end applications / systems that need it at this point. The killer use-case

Re: [HACKERS] continuing daily testing of dbt2 against

PROTECTED] wrote: Luke Lonergan wrote: +1 Mark, can you quantify the impact of not running with IRQ balancing enabled? Whoops, look like performance was due more to enabling the --enable-thread-safe flag. IRQ balancing on : 7086.75 http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158

Re: [HACKERS] continuing daily testing of dbt2 against

+1 Mark, can you quantify the impact of not running with IRQ balancing enabled? - Luke Msg is shrt cuz m on ma treo -Original Message- Original message contents unavailable ---(end of broadcast)--- TIP 9: In versions below 8.0, the

Re: [HACKERS] Query Failed, out of memory

Create table as select ... Order by ... Copy to ... - Luke Msg is shrt cuz m on ma treo -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 12:51 PM Eastern Standard Time To: Tom Lane Cc: Mark Woodward;

Re: [HACKERS] Query Failed, out of memory

:-D Is that in the release notes? - Luke Msg is shrt cuz m on ma treo -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 02:35 PM Eastern Standard Time To: Luke Lonergan Cc: Andrew Dunstan; Tom Lane; Mark Woodward; pgsql-hackers

Re: [HACKERS] Netflix Prize data

Mark, On 10/4/06 1:43 PM, Mark Woodward [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~/netflix$ time psql netflix -c select count(*) from ratings count --- 100480507 (1 row) real2m6.270s user0m0.004s sys 0m0.005s I think you are getting about 40MB/s on your

Re: [HACKERS] PG qsort vs. Solaris

+1 - Luke On 10/3/06 2:58 PM, Mark Kirkwood [EMAIL PROTECTED] wrote: Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Given the time that has been spent working around the braindamaged behavior of qsort() on various platforms, I would be more inclined to *always* use our qsort()

Re: [HACKERS] Faster StrNCpy

Mark, On 9/29/06 2:59 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Here are results over 64 Mbytes of memory, to ensure that every call is a cache miss: On my Mac OSX intel laptop (Core Duo, 2.16 GHz, 2GB RAM, gcc 4.01): Luke-Lonergans-Computer:~/strNcpy-perf-test lukelonergan$ gcc -O3

Re: [HACKERS] PostgreSQL 8.2beta1 w/ VALUES

That seems right, there won't be a performance impact unless the warnings are issued. - Luke Msg is shrt cuz m on ma treo -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Saturday, September 30, 2006 01:48 PM Eastern Standard Time To: Stephen Frost Cc:

Re: [HACKERS] New version of money type

Though this may be the kiss of death, I favor a 64 bit float version of money. It's more terse than numeric and a *lot* faster when performing numeric operations because it would use a cpu intrinsic operand. - Luke Msg is shrt cuz m on ma treo -Original Message- From: D'Arcy J.M.

Re: [HACKERS] New version of money type

Lonergan Cc: pgsql-hackers@postgreSQL.org Subject:Re: [HACKERS] New version of money type On Thu, 28 Sep 2006 11:09:17 -0400 Luke Lonergan [EMAIL PROTECTED] wrote: Though this may be the kiss of death, I favor a 64 bit float version of money. It's more terse than numeric and a I

Re: [HACKERS] New version of money type

D'Arcy, On 9/28/06 8:43 AM, D'Arcy J.M. Cain darcy@druid.net wrote: On Thu, 28 Sep 2006 10:35:01 -0500 Jim C. Nasby [EMAIL PROTECTED] wrote: Floating point math and hard-earned money are two things that don't mix well. :) Using FP to track money is a good way to stop making any. :-)

Re: [HACKERS] New version of money type

D'Arcy, On 9/28/06 9:00 AM, Luke Lonergan [EMAIL PROTECTED] wrote: Which routines implement the money arithmetic? Ok - so now having read the old documentation and the routine backend/utils/adt/cash.c and the type definition for Cash in backend/include/utils/adt/cash.h I can see that it's

Re: [HACKERS] New version of money type

Stephen, On 9/28/06 9:44 AM, Stephen Frost [EMAIL PROTECTED] wrote: I'm not sure about 'money' in general but these claims of great performance improvments over numeric just don't fly so easily with me. numeric isn't all *that* much slower than regular old integer in the tests that I've

Re: [HACKERS] New version of money type

D'Arcy, On 9/28/06 10:12 AM, D'Arcy J.M. Cain darcy@druid.net wrote: Numeric has been shown to be as good or better than money in I/O operations. What exactly does that mean in the context of a Datum: I/O operations? - Luke ---(end of

Re: [HACKERS] New version of money type

Martijn, On 9/28/06 11:53 AM, Martijn van Oosterhout kleptog@svana.org wrote: Converting to/from text format for when dealing with client applications. Numeric can convert faster than plain integers sometimes. Numeric isn't that slow really... Got it - so the performance benefits of the

Re: [HACKERS] New version of money type

Martijn, On 9/28/06 12:42 PM, Martijn van Oosterhout kleptog@svana.org wrote: - Only supports one currency (dollars) What are the manifestations of this? - Only supports one scale (yen has no decimal normally, but what if you want to track hundredths of a dollar-cent?) So, without a

Re: [HACKERS] horo(r)logy test fail on solaris (again and

I suspect the '-fast' introduced arithmetic associativity transformations that horology is sensitive to. I've seen this in the past. The solution I used was to mod the Makefile to exclude the sensitive routines from the aggressive optimizations. As I recall, adt.c was the prime culprit. -

Re: [HACKERS] horo(r)logy test fail on solaris (again and

Tom, On 9/26/06 9:15 AM, Tom Lane [EMAIL PROTECTED] wrote: Andrew Dunstan [EMAIL PROTECTED] writes: ! | @ 6 years | @ 5 years 12 mons 5 days 6 hours Doesn't this look odd regardless of what bad results come back from the FP library? It looks exactly like the

Re: [HACKERS] Bitmap index status

Mark, On 9/25/06 11:32 AM, Mark Wong [EMAIL PROTECTED] wrote: Yeah, basically gather as many stats as I can to accurately profile the overall system performance. I thought it would be appropriate to use a TPC-H based workload as one measuring stick to use for bitmap indexes. Note that the

Re: [HACKERS] PostgreSQL 8.2beta1 w/ VALUES

Josh, Anyhow, don't know if there's really a good solution but it'd be nice to only get one warning, or one of a given type, or something, and to Except that one warning would not be accurate, because the warning is per tuple. How is postgresql going to know that the warning

Re: [HACKERS] pg_upgrade: downgradebility

We would help if we do it in an open pgfoundry project. Bizgres? - Luke Msg is shrt cuz m on ma treo -Original Message- From: Josh Berkus [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 11:08 PM Eastern Standard Time To: Jonah H. Harris Cc:

Re: [HACKERS] New job

Congrats Jim! - Luke Msg is shrt cuz m on ma treo -Original Message- From: Jim C. Nasby [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 02:12 PM Eastern Standard Time To: pgsql-hackers@postgresql.org Subject:[HACKERS] New job While I'm sitting here in New

Re: [HACKERS] Sort performance

What version of pgsql? Recent changes stripped the sort set down considerably in size in external sort, I'm not sure the same is done if the data doesn't spill to disk. - Luke Sent by GoodLink (www.good.com) -Original Message- From: Gregory Stark [mailto:[EMAIL PROTECTED] Sent:

Re: [HACKERS] PostgreSQL on 64 bit Linux

Naz, On 8/20/06 12:59 PM, Naz Gassiep [EMAIL PROTECTED] wrote: I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not done

Re: [HACKERS] PostgreSQL on 64 bit Linux

Josh, On 8/20/06 8:52 PM, Joshua D. Drake [EMAIL PROTECTED] wrote: Is that true of even Woodcrest? Joshua D. Drake Not sure - haven't read anything about the register set on the Core 2 to make me think it benefits from 64 bit. The point may be academic from now on though - the comparisons

Re: [HACKERS] OTRS

Peter, On 8/19/06 5:37 PM, Peter Eisentraut [EMAIL PROTECTED] wrote: OTRS was recommended to me as a bug tracker. Has anyone used that? We use OTRS for customer issue tracking, but we use Jira from Atlassian for our internal bug tracking. We also use Confluence and Fisheye from Atlassian,

Re: [HACKERS] new job

+! - Luke On 8/9/06 11:48 AM, David Fetter [EMAIL PROTECTED] wrote: On Wed, Aug 09, 2006 at 01:58:14PM -0400, Jonah H. Harris wrote: On 8/9/06, Devrim GUNDUZ [EMAIL PROTECTED] wrote: Congratulations for your new job. Seconded! We now have a quorum. ;) I vote yes! Cheers, D

Re: [HACKERS] 8.2 features status

Greg, As I've stated before, it sure would be nice if there was any possible way this could be done for 8.2. This would be a *huge* feature for 8.2 to have, and it frankly needs all the big-item-yet-easy-to-grasp features it can get. Is there any way this could be done if we threw money

Re: [HACKERS] 8.2 features status

+1 UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then we'd be able to claim complete support for partitioning, but this is a big deal improvement. - Luke On 8/3/06 9:30 PM, Gavin Sherry [EMAIL PROTECTED] wrote: A lot of the things on Tom's list are new bits of

Re: [HACKERS] 8.2 features status

David, On 8/3/06 11:02 PM, David Fetter [EMAIL PROTECTED] wrote: * Splitting queries among CPUs--possibly even among machines--for OLAP loads * In-place upgrades (pg_upgrade) * Several varieties of replication, which I believe we as a project will eventually endorse and ship *

Re: [HACKERS] 8.2 features status

Josh, On 8/4/06 7:47 AM, Joshua D. Drake [EMAIL PROTECTED] wrote: 3) Index only access (new) Does this mean, I have hit the index and have the actual tuple data in the index row? So I don't have to go back to the relation to get the info? Yep. Fix the visibility issue - there are a number

Re: [HACKERS] 8.2 features status

) -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Friday, August 04, 2006 12:39 PM Eastern Standard Time To: Luke Lonergan Cc: Gavin Sherry; Bruce Momjian; pgsql-hackers@postgresql.org Subject:Re: [HACKERS] 8.2 features status Luke Lonergan [EMAIL

Re: [HACKERS] Hash indexes (was: On-disk bitmap index patch)

Jim, On 7/28/06 12:27 PM, Jim C. Nasby [EMAIL PROTECTED] wrote: In that case, perhaps this is something Greenplum might be interested in, since it might fit nicely between bitmap and btree indexes. I'm certainly following the thread. We have talked about hash and btree organized tables both

Re: [HACKERS] On-disk bitmap index patch

Bruce, On 7/29/06 6:31 AM, Bruce Momjian [EMAIL PROTECTED] wrote: Right. People need a patch to test on their workloads, and analysis can be done after feature freeze. Fair enough. - Luke ---(end of broadcast)--- TIP 5: don't forget to

Re: [HACKERS] On-disk bitmap index patch

Jim, On 7/28/06 10:17 AM, Jim C. Nasby [EMAIL PROTECTED] wrote: If the usefulness of bitmap indexes is still in doubt, could someone at Greenplum provide data from actual data warehouses from actual customers? First, is anyone in doubt? - Luke ---(end of

Re: [HACKERS] On-disk bitmap index patch

Bruce, On 7/28/06 1:25 PM, Bruce Momjian [EMAIL PROTECTED] wrote: What we don't want to happen is for us to release bitmapped indexes, and find out later that btree is better in all cases. Then we have to tell people not to use bitmapped indexes until we fix it in the next major releasse.

  1   2   3   >