[HACKERS] Removing the performance gap caused by CHECKPOINT

On postgresql anniversary summit there was a presentation byt SRA people about using background writer to do CHECKPOINTs which seemed very effective for removing the performance gap caused by CHECKPOINT. Has any of it been submitted for 8.2 ? -- Hannu Krosing Database Architect

Re: [HACKERS] An Idea for planner hints

be a way to not collect an exponential volume of statistics on > all column combinations. I understood that the proposal was to collect only the stats where needed (determined by user/dba) and use some rule-of-thumb values if no collected stats were available. -- Hannu Krosing Da

Re: [HACKERS] [PATCHES] Forcing current WAL file to be archived

Ühel kenal päeval, L, 2006-08-12 kell 10:59, kirjutas Tom Lane: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > Ühel kenal päeval, K, 2006-08-09 kell 10:57, kirjutas Tom Lane: > >> Insert points to the next byte to be written within the internal WAL > >> buffers.

Re: [HACKERS] [PATCHES] Forcing current WAL file to be archived

Ühel kenal päeval, K, 2006-08-09 kell 10:57, kirjutas Tom Lane: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > Ühel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs: > >> Methinks it should be the Write pointer all of the time, since I can't > >>

Re: [HACKERS] new job

. :D Has always been more like a meritocracy here ;) > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Hannu Krosing Database Architect Skype Techn

Re: [HACKERS] standard interfaces for replication providers

>other systems as well. > > > > So far, they are only partly usable for replication. I never looked into > > materialized views or anything else that would benefit from such triggers. > > > > Regards > > > > Markus > > > > --

Re: [HACKERS] [PATCHES] Forcing current WAL file to be archived

as if all the wal files together form one huge tape, without any gaps between ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(

Re: [HACKERS] "Constraint exclusion" is not general enough

ut a table constraint > anywhere in sight. I'd just keep the name. the parts of WHERE cluse can be described as constraints on what is returned :) -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Esto

Re: [HACKERS] 8.2 features status

res that were missing before were as easy to work around :) > Again, nothing wrong with that. Sure. Actually I think that people were able to work around missing features in 8.0/8.1 as well. The proof being, that people *did* actually use postgresql before 8.x , some even on win32 ;) -- ---

Re: [HACKERS] Hash indexes

Are you sure about the badness of our hash functions ? I just tested and hashtext(text) has about 1.4% of collisions on about 120M distinct texts, which is not bad considering thet total space for hashes is 4G, meaning that 120M covers itself already 3% of possible hash space. -- --

Re: [HACKERS] Forcing current WAL file to be archived

7;s get that > > done first and then think about automatic switches. > > Agreed. Simon, did you (or anybody else) manage to complete the patch for adding the (wal_filename, offset) returning function ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akade

Re: [HACKERS] Connection limit and Superuser

s > illusory anyway. I guess they want protection against accidentally using up all connections, not to have a way for competing superusers to locking each other out; -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia S

Re: [HACKERS] Formulating an sql query with CTID

. > > http://www.postgresql.org/docs/7.4/static/queries-select-lists.html > > That's for an older version, but it still works the same, google isn't > delivering the newer version... replace /7.4/ with /8.1/ to get a newer version ;) > Have an nice day, -- ---

Re: [HACKERS] On-disk bitmap index patch

ee several times faster for the cases where bitmap indexes are faster now :) -- -------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(

Re: [HACKERS] On-disk bitmap index patch

ge. IIRC the tests showing bitmap indexes being much faster on TPC-H were done on postgresql, no ? You pointed out that btree indexes are more bloated in this case as they store padding spaces for all CHAR(N) fields whereas bitmap index stores padding spaces only once for each distinct value.

Re: [HACKERS] The vacuum-ignore-vacuum patch

Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby: > On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote: > > > The other POV is that we don't really care about long-running > > > transaction in other databases unless they are lazy vac

Re: [HACKERS] GUC with units, details

regards, tom lane > > ---(end of broadcast)------- > TIP 5: don't forget to increase your free space map settings -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618,

Re: [HACKERS] The vacuum-ignore-vacuum patch

erializable transaction is the oldest one. -- ---- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end o

Re: [HACKERS] The vacuum-ignore-vacuum patch

h the tuples in the table being vacuumed as it locks out VACUUM on the indexed table. That would probably be quite easy to do by just having CONCURRENT CREATE INDEX also mark its transactions as ignorable by VACUUM. Maybe the variable name for that (proc->inVacuum) needs to be changed to somethi

Re: [HACKERS] Better name/syntax for "online" index creation

Ühel kenal päeval, K, 2006-07-26 kell 13:23, kirjutas Gregory Stark: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > > Ãœhel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark: > > > The DB2 handbook says "Tables can now be reorganized online with a

Re: [HACKERS] [PATCHES] [PATCH] Provide 8-byte transaction IDs to

committed between two snapshots. > But at this point I wouldn't hold my breath on that Well, switching to using stuff from this patch would fix the data-corruption-after-2G problem for slony. That is unless thera are some bugs or thinkos of its own in this patch :) --

Re: [HACKERS] [PATCHES] Resurrecting per-page cleaner for btree

sted solution for that was the dead space map. That > way vacuum can ignore parts of the table that havn't changed... It can ignore parts of the *table* but still has to scan full *indexes*. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Talli

Re: [HACKERS] [PATCHES] [PATCH] Provide 8-byte transaction IDs to

pg_sync_txid allows use of pg_dump for moveing database, > > but also adds possibility to shoot in the foot by allowing > > epoch wraparound to happen. Is "Don't do it then" enough? > > * Currently txid keeps its own copy of nextxid in pg_control, > > this makes

Re: [HACKERS] [PATCHES] [PATCH] Provide 8-byte transaction IDs to

regards, tom lane > > > > ---(end of broadcast)--- > > TIP 2: Don't 'kill -9' the postmaster > -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 1

Re: [HACKERS] Better name/syntax for "online" index creation

> EnterpriseDB http://www.enterprisedb.com > > > > > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column'

Re: [HACKERS] On-disk bitmap index patch

izen index AMs, and that's why I'm questioning > what the scope of applicability of bitmap indexes really is. They need > to be popular enough that people will be motivated to work on them, > or they shouldn't be in core. Is there an easy way to put them into contrib/ fo

Re: [HACKERS] On-disk bitmap index patch

any people > > there (more than 5) really wanted to use it as a standard feature. > > > > A version of the slides with only the bitmap index results are located here: > > http://intranet.greenplum.com/bitmap-index-perf-ayush.ppt. > > 404 Strange. I can download it both f

Re: [HACKERS] Forcing current WAL file to be archived

have a problem... This should not happen. your streaming process should be smart enought to guarantee that. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com

Re: [HACKERS] Forcing current WAL file to be archived

Ühel kenal päeval, T, 2006-07-25 kell 11:48, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > ?hel kenal p?eval, T, 2006-07-25 kell 11:27, kirjutas Bruce Momjian: > > > Hannu Krosing wrote: > > > > ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momj

Re: [HACKERS] Forcing current WAL file to be archived

Ühel kenal päeval, T, 2006-07-25 kell 11:27, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momjian: > > > Where are we on these TODO items: > > > > > > > > o Add reporting o

Re: [HACKERS] Better name/syntax for "online" index creation

rd ... At some point we may add some other ops we start doing CONCURRENTLY, like perhaps CLUSTER CONCURRENTLY or even ALTER TABLE CONCURRENTLY ADD COLUMN x DEFAULT nextval('s'); and other table rewriting ops. -- Hannu Krosing Database Architect Skype Technolog

Re: [HACKERS] Forcing current WAL file to be archived

een WAL write and notification, but just the function would also go a long way. > Seems they should be completed for 8.2. I have only a /contrib version for > the last one. -- ---- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Sky

Re: [HACKERS] On-disk bitmap index patch

something that is still faster than btree for several usecases. And also for AND-s of several indexes, where indexes are BIG, your btree indexes may be almost as big as tables but the resulting set of pages is small. -- Hannu Krosing Database Architect Skype Technologies OÜ Akad

Re: [HACKERS] "hot standby" system

me to do it after coming back. But it will be on PgFoundry eventually. Marko has the details if you need it faster -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skyp

Re: [HACKERS] Transaction Speed and real time database

load on db that you always meet your time limit. Remember, RT does not neccesarily mean Fast it just needs to be Predictable! -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get S

Re: [HACKERS] How does the planner deal with multiple possible

? Currently the closest thing is BEGIN; DROP INDEX xxx; test query here ABORT; > Otherwise I'll try > and come up with a test case. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Sk

Re: [HACKERS] BF Failure on Bandicoot

Ühel kenal päeval, R, 2006-07-21 kell 17:14, kirjutas Sandeep Jakkaraju(Navolve): > Hi All > > > I am looking for a C/C++ library which can talk to postgresql/postgis > other than libpqxx!! Why ? > thanx in advance > > sandeep -- ---- Hannu Krosing

Re: [HACKERS] Progress bar updates

r > until it has results and then stream the ajax to display the results. Having > to get the backend pid before your query and then open a second database > connection to monitor your first connection would be extra footwork for > nothing. You would have to do some extra work anywa

Re: [HACKERS] [SQL] using constraint based paritioning to fix EAV

Ühel kenal päeval, K, 2006-07-19 kell 00:20, kirjutas Hannu Krosing: > Ühel kenal päeval, T, 2006-07-18 kell 16:44, kirjutas Andrew Hammond: > > On 7/18/06, Aaron Bono <[EMAIL PROTECTED]> wrote: > > On 18 Jul 2006 09:07:08 -0700, Andrew Hammond > >

Re: [HACKERS] [SQL] using constraint based paritioning to fix EAV

ute1 text, > attribute2 text, > attribute3 text, > attribute4 text, > ... > ); Maybe you can approach the problem from another end, and make the many_tables table the virtual one and all th

Re: [HACKERS] plpython sets

setof" enabled > plpython.c. Now built and working fine! > > Do someone know why the back-end effort is duplicated? http://python.projects.postgresql.org/ seems to be aiming at a much larger python/postgres integration scheme than src/pl/python. and it has taken a different and more

Re: [HACKERS] plPHP and plRuby

nice to have the not-included PLs present in src/pl/ as their own directories with a README.TXT containing fetch and build instructions So we would have src/pl/plphp/README.TXT src/pl/pljava/README.TXT src/pl/plj/README.TXT and anybody looking for pl-s would find the info in a logical place --

Re: [HACKERS] plpython sets

parameters (args[] still valid) * returning composite types (dict, tuple, list, class) * returning SETOF as any iterable object (list, tuple, iterator, generator) -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618

Re: [HACKERS] Online index builds

Ühel kenal päeval, L, 2006-07-15 kell 21:10, kirjutas Greg Stark: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > > Maybe we can show progress indicators in status line (either > > pg_stat_activity.current_query or commandline shown in ps), like > > > > WA

Re: [HACKERS] Forcing wal rotation

Ühel kenal päeval, L, 2006-07-15 kell 22:24, kirjutas Tom Lane: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > And by any chance, do you plan to backport the standby WAL playback mode > > patches to 8.0 and 8.1 series ? > > That's not happening ... we do not put

Re: [HACKERS] Online index builds

ECT COUNT(*) can sometimes be a "mainenance operation" and thus the goal may not be to complete as fast as possible, but to be as light as possible on concurrent OLTP queries. Eventually it would nice to have special optimiser rules for any "maintenance" queries and DDL ops a

Re: [HACKERS] Forcing wal rotation

could do async wal-copying at the time WAL is being written instead of copying it all when it is finished. This could reduce the lag of data availability to only (fractions of) seconds. Is anyone working on it ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemi

Re: [HACKERS] Three weeks left until feature freeze

e types and operators for calculations instead of converting types to pl's native types. and it also has lots of code lines ;) -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free:

Re: [HACKERS] pgsql-patches considered harmful

ICQ . 7615664 > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column's datatypes do not >match -- Hannu Krosing Database A

Re: [HACKERS] Three weeks left until feature freeze

) languages > It would be nice to have an easy way to retrieve and install the desired PL's > but that's more of a packaging issue. > -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkro

Re: [HACKERS] More nuclear options

oject he/she/it has a place to get the code from. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--

Re: [HACKERS] Three weeks left until feature freeze

ava. Maybe this functionality could be lifted out of PL/Java and made available to all PL-s ? At least at some API level. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Sk

Re: [HACKERS] Max size of a btree index entry

se, a quick archives search of -SQL, -Newbie and -General would > indicate how popular of an issue this is. It may become populat again, when we will be able to do index-only scans. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12

Re: [HACKERS] Warm-Standby using WAL archiving / Seperate

ue, which although workable, > has a bit of a house-of-cards feel to it sometimes. > -- -------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com

Re: [HACKERS] A couple thoughts about btree fillfactor

date cases. So perhaps we should set the minimum to 1% or even 0.1% and apply similar logic you suggested for btree pages above, that is stop adding new ones when the threasold is reached. > Comments? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21

Re: [HACKERS] update/insert, delete/insert efficiency WRT vacuum

true for all db systems > when using this strategy). I think the recommended strategy is to first try tu UPDATE, if not found then INSERT, if primary key violation on insert, then UPDATE -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn

Re: [HACKERS] Index corruption

log_origin in the heap tuple will > filter them out. The problem was not only with returning too many rows from tuples, but as much returning too few. In case when you return too few rows some actions will just be left out from replication and thus will be missing from slaves. -- --

Re: [HACKERS] Index corruption

thing that seemed to mess up something inside there, was when change on parent rownt fired a trigger that changes child table rows and there rows fired another trigger that changed the same parent row again. -- Hannu Krosing Database Architect Skype Technologies OÜ Ak

Re: [HACKERS] Index corruption

eplicas from > scratch :-(. How well did you check the C-language triggers and special slony functions for possibly corrupting some backend/shared-mem structures ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me:

Re: [HACKERS] Single Index Tuple Chain (SITC) method

replacing dead entry) Espacially in the case, where you replace an index entryu with the same value. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com -

Re: [HACKERS] vacuum, performance, and MVCC

Ühel kenal päeval, T, 2006-06-27 kell 12:16, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > ?hel kenal p?eval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing: > > > ?hel kenal p?eval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian: > > > > Jim C. Nasby wrote:

Re: [HACKERS] Single Index Tuple Chain (SITC) method

like VACUUM, but I seriously doubt > anyone will find it acceptable for UPDATE. It could easily create > application-level deadlocks, too. (VACUUM is safe against that because > it only holds one lock.) Tom - what do you think of the other related idea, that of reusing dead index entries ? -- --

Re: [HACKERS] vacuum, performance, and MVCC

Ühel kenal päeval, E, 2006-06-26 kell 11:31, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > > > pass 3: clean heap based on ctid from pass 1 > > > > > > > > If yo do it this way, you dont need to invent new data structures to > > > > pas

Re: [HACKERS] vacuum, performance, and MVCC

Ühel kenal päeval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing: > Ühel kenal päeval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian: > > Jim C. Nasby wrote: > > > On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote: > > > > > > > > I

Re: [HACKERS] vacuum, performance, and MVCC

n for ITPC. > > I understood what you had said. The question is whether we want to get > that complex with this feature, and if there are enough use cases > (UPDATE with index keys changing) to warrant it. I'd like to think that most heavily-updated tables avoid that, but there may

Re: [HACKERS] vacuum, performance, and MVCC

where bitmap index scan fit into all of this. Is > preserving the sequential scan aspect of these a goal with this new > setup? Bitmap index scan does not have to change much - only the function that gets tuple by its ctid must be able to trace forward chains within the page. --

Re: [HACKERS] vacuum, performance, and MVCC

Ühel kenal päeval, E, 2006-06-26 kell 10:50, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > ?hel kenal p?eval, E, 2006-06-26 kell 14:56, kirjutas Martijn van > > Oosterhout: > > > On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote: > > > > Correc

Re: [HACKERS] vacuum, performance, and MVCC

e. > > The original suggestion, was nothing more than a hypothetical for the > purpose of discussion. > > The problem was the steady degradation of performance on frequent updates. > That was the point of discussion. I brought up "one possible way" to > start a &q

Re: [HACKERS] vacuum, performance, and MVCC

hould free space map be notified about free space in pages with CITC chains ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---

Re: [HACKERS] vacuum, performance, and MVCC

t this is not relevant to current discussion). -- ---- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--

Re: [HACKERS] vacuum, performance, and MVCC

by tuning the system to not put more than N new rows on the same page at initial insert or when the row move to a new page during update. Currently several new rows are initially put on the same page and then move around during repeated updates until they slow(ish)ly claim their own page. > Do

Re: [HACKERS] vacuum, performance, and MVCC

Ühel kenal päeval, L, 2006-06-24 kell 19:36, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > ?hel kenal p?eval, R, 2006-06-23 kell 13:08, kirjutas Tom Lane: > > > > > > Bottom line: there's still lots of low-hanging fruit. Why are people > > > fee

Re: [HACKERS] vacuum, performance, and MVCC

rows that are invisible to all running transactions. Currently we just mark these index entries as dead, but maybe there is a way to reuse them. This could solve the index bloat problem for may cases. Another possible solution for indexes with mostly dead pointers is doing a reindex, but this will

Re: [HACKERS] vacuum, performance, and MVCC

y assumption on how index lookup works, and very much simplified view of how different parts of the system work to implement MVCC. The original fix he "suggests" was to that imagined behaviour and thus ignored all the real problems of such change. All the next suggestions were variation

Re: [HACKERS] vacuum, performance, and MVCC

causes nearly as much disk io as removing the node. If we could delete/reuse old index tuples, it would solve a sizable chunk of index-growth problem, especially for cases where referenced key value does not change. -- Hannu Krosing Database Architect Skype Technologies OÜ

Re: [HACKERS] vacuum, performance, and MVCC

the whole current > vacuum stuff with a background thread which does that continuously using > a dead space map. That could be a heap sorted by tuple deletion time, > and always cleaned up up to the oldest running transaction's start > time... there would be no need for any other au

Re: [HACKERS] vacuum, performance, and MVCC

es between runs. > > And how much I/O does this take? Surprisingly its mostly WAL traffic, the heap/index pages themselves are often not yet synced to disk by time of vacuum, so no additional traffic there. If you had made 5 updates per page and then vacuum it, then you make effective

Re: [HACKERS] vacuum, performance, and MVCC

nk of a few > difficulties off the top of my head, but it would solve the steady > degradation of performance between vacuums and, to a possibly lesser > extent, the cost of updating a row in a heavily indexed table. VACUUMing often also solves the problem of "steady degrada

Re: [HACKERS] vacuum, performance, and MVCC

is problem, and it can get really really bad. Usually it gets really bad if you *don't* run vacuum continuously, maybe hopeing to do it in slower times at night. For high-update db you have to run it continuously, maybe having some 5-15 sec pauses between runs. -- Hannu Krosing Database Ar

Re: [HACKERS] vacuum, performance, and MVCC

g at 100% IO saturation, in which case it will be worse. The max throughput figure is not something you actually need very often in production. What is interesting is setting up the server so that you can service your loads comfortably. Running the server at 100% lead is not anything you want to do

Re: [HACKERS] vacuum, performance, and MVCC

of something that > does not scale. The more and more updates there are, the higher the load > becomes. You can see it on "top" as the footest program runs. Yes, you understood correctly - the more updates, the higher the load :) -- Hannu Krosing Database

Re: [HACKERS] Getting rid of extra gettimeofday() calls

en resetting the activity_string to > . Is it just or also ? If we are going to change things anyway, I'd like the latter to show the time since start of transaction, so that I Would at least have an easy way to write a transaction timeout script :) I don't really care about what

Re: [HACKERS] Rethinking stats communication mechanisms

ck_me in pg_functions. In this way you don't accidentally run out of shared mem by defining lots of new functions and then restarting the cluster. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me

Re: [HACKERS] [PATCHES] ADD/DROP INHERITS

ic of design goodness, but never a goal in itself. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)-

Re: [HACKERS] ADD/DROP constraints

nerate a > redundant constraint when it generates the table. Maybe that would go if > constraints got conislocal and coninh. Currently pg_dump generates all constraints with ONLY clause anyway. But I agree that we should get rid of ONLY for ADD CONSTRAINT once we disallow dropping inherited

Re: [HACKERS] ADD/DROP INHERITS

Ühel kenal päeval, N, 2006-06-08 kell 11:42, kirjutas Greg Stark: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > > Do you mean that in newer versions ALTER TABLE ADD COLUMN will change > > existing data without asking me ? > > > > That would be evil! >

Re: [HACKERS] How to avoid transaction ID wrap

Ühel kenal päeval, N, 2006-06-08 kell 12:09, kirjutas Tom Lane: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > If the aim is to *only* avoid transaction wraparound, then maybe we > > could introduce VACUUM FREEZE ONLY; which never removes any old tuples, > > but instead

Re: [HACKERS] ADD/DROP INHERITS

ld already have all the constraints of parent, but may have more. > We could do a pass-3 check for the NOT NULL constraint but if we're not doing > other schema changes then it makes more sense to just refuse to add such a > table. nono. the ADD/DROP INHERITS should not do any data

Re: [HACKERS] How to avoid transaction ID wrap

LY; which never removes any old tuples, but instead just marks them by setting xmin=xmax for them, in addition to its freezing of live-and-visible-to-all tuples. This would avoid touching indexes at all and may well be what is desired for tables with only very little updates/deletes. -- ---

Re: [HACKERS] More on inheritance and foreign keys

other table while changing values at either end. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)

Re: [HACKERS] How to avoid transaction ID wrap

ext, but often it *is* possible to design your system in a way where a superlong transaction is almost unnoticable. Long transactions are evil in case they cause some fast-changing table to grow its storage size several orders of magnitude, but if that is not the case then they just run there in back

Re: [HACKERS] ADD/DROP INHERITS

h just a possibility to move suitable ready-made partitions in and out of inheritance chain solves a really big problem. No need to try to obfuscate it with extra functionality, at least not initially. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn,

Re: [HACKERS] How to avoid transaction ID wrap

p. actually 4.5 months as you will start having problems at 2G xacts. > I am thinking about a few work arounds, BEGIN/COMMIT to reduce the number > of transactions, COPY, etc. so I'm not dead in the water, but I would be > interested in any observations yo may have. -- --

Re: [HACKERS] [PERFORM] psql -A (unaligned format) eats too much

due to error partway through the SELECT. would it not learn about it at the point of error ? even without --cursor there is still no very good way to find out when something else goes wrong, like the result inside libpq taking up all memory and so psql runs out of memory on formatting some longer lin

Re: [HACKERS] More thoughts about planner's cost estimates

Ühel kenal päeval, P, 2006-06-04 kell 18:09, kirjutas Tom Lane: > Greg Stark <[EMAIL PROTECTED]> writes: > > Hannu Krosing <[EMAIL PROTECTED]> writes: > >> Ühel kenal päeval, L, 2006-06-03 kell 10:43, kirjutas Jim Nasby: > >>> Might also b

Re: [HACKERS] More thoughts about planner's cost estimates

e disk or controller. -- -------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 9: In ver

Re: [HACKERS] More thoughts about planner's cost estimates

e more - so that there would be better chances of running those on busy databases without disastrous effects. Probably we should use the same settings for all these, not invent a new set for each. -- ---- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn,

Re: [HACKERS] session id and global storage

Ühel kenal päeval, N, 2006-06-01 kell 10:10, kirjutas David Hoksza: > It seems MyProcID is what I was searching for... > On a buzy server with lots of connects, procID will repeat quite often. -- ---- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia te

Re: [HACKERS] copy with compression progress n

gt; in a performant way. The issue already arises if psql or any other COPY > client (slony, pg_dump) is not on the same machine: Network bandwidth > will limit throughput. Maybe make up a way to pipe COPY result through some external process (like gzip) on the server side without hav

Re: [HACKERS] COPY FROM view

Ühel kenal päeval, P, 2006-05-28 kell 13:53, kirjutas Alvaro Herrera: > Hi, > > I've been having the COPY FROM patch that was posted on pgsql-patches > some time ago (I think from Hannu Krossing), Not by/from me :) -- -------- Hannu Krosing Database Architect Skyp

<    4   5   6   7   8   9   10   11   12   13   >