Re: [HACKERS] REVIEW: pg_stat_statements with query tree based normalization

2012-01-21 Thread Kääriäinen Anssi
I am going to produce another revision in response to feedback already received. I intend to outline the steps that it will take to resolve some outstanding issues in the next day or so. It would be nice if you could take a look at the revised patch that is ultimately produced. Should I keep you

[HACKERS] REVIEW: pg_stat_statements with query tree based normalization

2012-01-20 Thread Kääriäinen Anssi
This is a short review of pg_stat_statements based on quick testing of the feature. 1. Installation: after managing to actually build PostgreSQL and contrib modules + changing shared_preload_libraries to include pg_stat_statements I got this error: FATAL: could not create shared memory

Re: [HACKERS] Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message

2011-11-10 Thread Kääriäinen Anssi
What I want to find in the end is something which tells me this row causes the error. Unfortunately, as the new row of the table with the constraint is not yet on disk, it doesn't really have its own ctid, and therefore I cannot report that. (Which makes sense, obviously.) Would an error with

Re: [HACKERS] So, is COUNT(*) fast now?

2011-10-30 Thread Kääriäinen Anssi
Quoting Robert Haas: I tried this on my MacBook Pro this morning, using pgbench -i -s 500 to create a database about 7.5GB in size, and then using SELECT sum(1) FROM pgbench_accounts as a test query, on a build WITHOUT --enable-cassert. This machine has 4GB of memory, and I set shared_buffers =

Re: [HACKERS] So, is COUNT(*) fast now?

2011-10-30 Thread Kääriäinen Anssi
Sorry, I forgot to include the version used some information about my setup: PostgreSQL version: Git HEAD as of: Date: Fri Oct 28 21:18:36 2011 -0400 Commit: 51eba98cf4595e90730dedd9305da8aa84b649ee Compiled with defaults, (only change --with-pgport = 5431). I used default settings,

Re: [HACKERS] Index only scan paving the way for auto clustered tables?

2011-10-11 Thread Kääriäinen Anssi
Robert Haas wrote: And it seems to me that there could easily be format changes that would make sense for particular cases, but not across the board, like: - index-organized tables (heap is a btree, and secondary indexes reference the PK rather than the TID; this is how MySQL does it, and Oracle

Re: [HACKERS] pg_cancel_backend by non-superuser

2011-10-01 Thread Kääriäinen Anssi
In *every* case -- and there are many -- where we've had people express pain, this would have sufficed. Usually the problem is a large index creation gone awry, or an automated backup process blocking a schema change that has taken half the locks it needs, or something like that -- all by the

Re: [HACKERS] index-only scans

2011-08-13 Thread Kääriäinen Anssi
Now, suppose that we know that 50% of the heap pages have their visibility map bits set. What's the chance that this query won't need a heap fetch? Well, the chance is 50% *if* you assume that a row which has been quiescent for a long time is just as likely to be queried as one that has been


2011-02-11 Thread Kääriäinen Anssi
From: [] On Behalf Of Tom Lane [] Sent: Friday, February 11, 2011 7:35 PM To: Dimitri Fontaine Cc: David E. Wheeler; Robert Haas; Josh Berkus;

Re: [HACKERS] SSI and Hot Standby

2011-01-21 Thread Kääriäinen Anssi
When I test your example, though, I'm getting the serialization failure on T3 rather than T2, so I'd call that a bug. Will investigate. Thanks again for your tests! You seem to be able to shake out issues better than anyone else! Once found, fixing them is not usually very hard, it's coming up

Re: [HACKERS] REVIEW: Extensions support for pg_dump

2011-01-17 Thread Kääriäinen Anssi
Well I'm not seeing that here I am not at work at the moment and I don't have the possibility to compile PostgreSQL on this computer, so the example here is from memory. The issue I saw was this: assume you have an extension foo, containing one function, test(). CREATE EXTENSION foo; DROP