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
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
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
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 =
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,
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
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
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
From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
On Behalf Of Tom Lane [t...@sss.pgh.pa.us]
Sent: Friday, February 11, 2011 7:35 PM
To: Dimitri Fontaine
Cc: David E. Wheeler; Robert Haas; Josh Berkus;
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
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
11 matches
Mail list logo
