Re: [HACKERS] contrib/pg_stat_statements 1226

required physical reads for example. The system-wide stats satisfy a very different need from this. The sysadmin or DBA might want to know about system-wide stats but a programmer or a DBA analyzing a specific query needs to know what that query is doing. -- Gregory Stark EnterpriseDB

Re: [HACKERS] QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows)

for the first few blocks, the later blocks can be stored uncompressed? Or is that too complicated compared to what we have now? :-) Actually we do that now, it was part of the same patch we're discussing. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows)

it at all. But if you added one more attribute we would go to great lengths compressing and storing attributes externally -- not necessarily the attribute you just added, the ones that were perfectly fine previously -- to try to get it under 2k. -- Gregory Stark EnterpriseDB http

Re: [SPAM] Re: [HACKERS] posix_fadvise v22

, 1250, 1251, 1252, 1253, 1254, 1350, 1358, 1394, 1438, 1498, 1534 Visit http://sources.redhat.com/bugzilla/ for the details of each bug. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql

Re: [HACKERS] incoherent view of serializable transactions

standard. It is an equivalent condition or a consequence, depending on how you view it. The standard explicitly says that the no-phantom-reads condition is a consequence of the serializability constraint. Did you miss that whole discussion this past week? -- Gregory Stark EnterpriseDB

Re: [HACKERS] posix_fadvise v22

is mostly in cache. In which case prefetching would be hard pressed to help at all. We could construct a synthetic case but the main point of this feature is to make use of raid arrays that are currently going idle, not to pick up a few percentage points for single spindle systems. -- Gregory Stark

Re: [HACKERS] Significantly larger toast tables on 8.4?

large data. If it's starved for i/o bandwidth but has spare cpu cycles then you will. If that's true then we really have to expose this parameter to users. There won't be a single value that is appropriate for everyone. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me

Re: [HACKERS] posix_fadvise v22

it hard to see a consistent benefit without a raid array. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] about truncate

a recursive version of the command to recluster an already clustered table though. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] About CMake

building. And in any case we want to use MSVC project files and MSVC's make-equivalent to actually drive the build which kind of rules out using the Makefile rules as-is. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent

Re: [HACKERS] Documenting serializable vs snapshot isolation levels

add new records which would have changed the results of the query. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] V3 of PITR performance improvement for 8.4 (WIP)

to prefetch. Why is that necessary instead of just keeping a count of how many blocks have been prefetched? Does it help avoid prefetching the same blocks repeatedly? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning

Re: [HACKERS] incoherent view of serializable transactions

that, or if you have examples of transactions which Sybase provides proper serialized semantics for but Postgres doesn't. But I am probably missing the point which was to fix the doc? But missing the point and having pointless arguments is so much more fun than documentation writing :) -- Gregory Stark

Re: [HACKERS] incoherent view of serializable transactions

clear that that's not the definition. Excluding P1,P2,P3 is necessary but not sufficient to meet the spec's definition of Serializable. Kevin Grittner kevin.gritt...@wicourts.gov writes: Gregory Stark st...@enterprisedb.com wrote: Afaict doing a few google searches Sybase doesn't do predicate

Re: [HACKERS] Window-functions patch handling of aggregates

is a strength and we should leverage that. The burden of supporting more complex cases should be borne by the users that are bending the rules. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1324)

to know when they're no longer referenced. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Hot standby and b-tree killed items

think WAL replay should stick to stalling WAL replay and only resort to killing queries if the user specifically requests it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Hot standby and b-tree killed items

. Sure, it's a nice option to have. But I think the default should be to pause WAL replay. The question I had was whether your solution for btree pointers marked dead and later dropped from the index works when the user hasn't configured a timeout and doesn't want standby queries killed. -- Gregory

Re: [HACKERS] Hot standby and b-tree killed items

. This is something that can happen for any query any time, even plain old read-only select queries. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Hot standby and b-tree killed items

query -- and that's the *only* query in the database at all. A vacuum being replayed -- even in a different database -- could trigger the error. Or with the btree split issue, a data load -- again even in a different database -- would be quite likely cause your SELECT to be killed. -- Gregory

Re: [HACKERS] possible bug in 8.4

planning. Historically we couldn't because we didn't have plan invalidation -- and the plan you posted below with the Anti-Join is brand new in 8.4 -- so there is room for improvement but it's not exactly a bug. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] possible bug in 8.4

Tom Lane t...@sss.pgh.pa.us writes: Gregory Stark st...@enterprisedb.com writes: I think Postgres can't do better because there could be a NULL in the subquery. If there's a NULL in the subquery then no record would match. Yeah. NOT IN does not have the right semantics to become an antijoin

Re: [HACKERS] possible bug in 8.4

Grzegorz Jaskiewicz g...@pointblue.com.pl writes: all I know, is that the same query will work on 8.3 in reasonably acceptable time frame. What plan do you get in 8.3? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication

Re: [HACKERS] possible bug in 8.4

(cost=0.00..75177.00 rows=540 width=4) (5 rows) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Visibility map and freezing

-frozen xids are relfrozenxid+100M. When we find all the bits set we can clear them all and bump relfrozenxid by 100M. This would allow regular partial vacuums to gradually move the frozenxid forward. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] Variadic parameters vs parameter defaults

with that. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Invalid pages in WAL

that? Regrettably, none. I will ask to see if the sequence of actions can be repeated, but that may not get us anywhere. This was with CVS HEAD? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers

Re: [HACKERS] Another issue in default-values patch: defaults expanded too soon

: ProcedureCreate, pg_proc.c:366 We could say that changing the type of a default argument for a polymorphic argument isn't allowed just like changing the return value. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql

Re: [HACKERS] Variadic parameters vs parameter defaults

than an empty array. I don't see a compelling reason. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Another issue in default-values patch: defaults expanded too soon

Tom Lane t...@sss.pgh.pa.us writes: Gregory Stark st...@enterprisedb.com writes: We could say that changing the type of a default argument for a polymorphic argument isn't allowed just like changing the return value. The point I was trying to make is that allowing defaults for polymorphic

Re: [HACKERS] Looking for someone with MinGW

to glibc. Don't we have plenty of BSD and other implementations? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Block-level CRC checks

contorting the existing code much. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: default values for function parameters

about everything. Anything you do using punctuation characters is going to look out of place. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] benchmarking the query planner

for a 100M row table doesn't seem like a reasonable solution to one metric being bogus. For that matter, if we do consider sampling 5% of the table we may as well just go ahead and scan the whole table. It wouldn't take much longer and it would actually produce good estimates. -- Gregory Stark

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1268)

together? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] benchmarking the query planner

. I'll look for it online. But it included a section which was a survey of past results from other papers and the best results required stupidly large sample sizes to get anything worthwhile. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1268)

selinux or row-acls. If their distribution decides not to compile in selinux support they just have one choice, row-acls (or nothing). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent

Re: [HACKERS] posix_fadvise v22

: Binary data -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] benchmarking the query planner

for large tables. Unfortunately _any_ ndistinct estimate based on a sample of the table is going to be pretty random. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] benchmarking the query planner

long 10,000 would take? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] posix_fadvise v22

Here's an update to eliminate two small bitrot conflicts. posix_fadvise_v22.diff.gz Description: Binary data -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] WIP: default values for function parameters

position here -- the more Oracle incompatibilities in stock Postgres the better for us. But afaik we don't emulate = anyways so that hardly matters. If anything it shows how unimportant it is to worry about being compatible on this front. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] contrib/pg_stat_statements 1202

... As stuff matures and becomes indispensable we could consider moving it to the regular EXPLAIN or implement some way to specify precisely which data the user wants. Or just say XML/table data/whatever will solve the problem for us. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com

Re: [HACKERS] new vacuum is slower for small tables

interesting. Without index-only scans it probably doesn't make much sense to create the visibility map until we hit something like 32 pages or so. Vacuum should be able to handle that many pages so fast that speeding it up seems pointless. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] In-place upgrade: catalog side

cannot do. If you crashed while during that it would leave you with half the table with the columns in the old attribute position and half the columns in the new attribute position. There would be no way to tell which was which. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends

extra conflicts. It would still cause any other pending patches for 8.5 to bitrot but from the sounds of things shouldn't be too hard to fix up. It seems to me we ought to do this regardless of whether we apply the functional changes. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends

cause the backend to die. The other way around could be useful too -- catching ereports/elogs within a backend API call from C++ code and throwing a C++ exception. I'm not sure if that's doable though. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] [postgis-devel] CLUSTER in 8.3 on GIST indexes break

Mark Cave-Ayland [EMAIL PROTECTED] writes: So in other words, the contents of the temporary table has just disappeared :( Uhm. That rather sucks. I was able to reproduce it too. It seems to happen after I pause for a bit, and not when I run the script in fast succession. -- Gregory Stark

Re: [HACKERS] Optimizing DISTINCT with LIMIT

it to here -- note that if we decide it isn't worth it it'll just get removed. http://wiki.postgresql.org/wiki/Todo -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Simple postgresql.conf wizard

width=102) (29 rows) Time: 1186.315 ms -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] [postgis-devel] CLUSTER in 8.3 on GIST indexes break

tuples being returned). If I executed the same select statement again, I would get the correct number of records. Sounds like this item fixed in 8.2.10: # Fix possible duplicate output of tuples during a GiST index scan (Teodor) -- Gregory Stark EnterpriseDB http

Re: [HACKERS] Simple postgresql.conf wizard

Greg Smith [EMAIL PROTECTED] writes: On Thu, 4 Dec 2008, Gregory Stark wrote: My point was more that you could have a data warehouse on a non-dedicated machine, you could have a web server on a non-dedicated machine, or you could have a mixed server on a non-dedicated machine. I should

Re: [HACKERS] In-place upgrade: catalog side

-- and if you crash in the middle your data will be toast. I don't see much reason to worry about dropping the attribute though. The only cases where it matters are if you're near MaxAttrNum (1600 columns IIRC) or if it's the only null column (and in a table with more than 8 columns). -- Gregory

[HACKERS] Assertion failure in new outer/semi/anti join code

of the join. Incidentally originally triggered with a VALUES clause but I think by the point the code runs that distinction is long gone. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing

Re: [HACKERS] In-place upgrade: catalog side

Zdenek Kotala [EMAIL PROTECTED] writes: Gregory Stark napsal(a): How about adding a special syntax for CREATE TABLE which indicates to include a dropped column in that position? Then pg_dump could have a -X option to include those columns as placeholders. Something like: CREATE TABLE foo

Re: [HACKERS] Optimizing DISTINCT with LIMIT

by x limit 5; -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Optimizing DISTINCT with LIMIT

Heikki Linnakangas [EMAIL PROTECTED] writes: Gregory Stark wrote: Does that know to stop scanning as soon as it has seen 5 distinct values? Uhm, hm. Apparently not :( postgres=# create or replace function v(integer) returns integer as $$begin raise notice 'called %', $1; return $1; end

Re: [HACKERS] Simple postgresql.conf wizard

is resistant to trying to optimize such queries but actually I've written lots of queries like that myself so I find them interesting. I'll look at the query and see if I can write a similar one using dbt3. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] Optimizing DISTINCT with LIMIT

. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] contrib/pg_stat_statements 1202

awkward for the simple case. I'm sure there are dozens of ways to skin this cat. Anyone have any more? We probably just have to pick one and run with it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql

Re: [HACKERS] In-place upgrade: catalog side

Greg Smith [EMAIL PROTECTED] writes: On Thu, 4 Dec 2008, Gregory Stark wrote: They all seem functional ideas. But it seems to me they're all ideas that would be appropriate if this was a pgfoundry add-on for existing releases. I was mainly trying to target things that would be achievable

Re: [HACKERS] maintenance memory vs autovac

if they're sure they're only running one at a time. But all of this isn't a new issue is it? I thought we've had multiple autovacuum workers since 8.3. Have there been any complaints? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS

Re: [HACKERS] Visibility map, partial vacuums

the cost_limit and hide all the other parameters as internal parameters. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Visibility map, partial vacuums

Heikki Linnakangas [EMAIL PROTECTED] writes: Gregory Stark wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Hmm. It just occurred to me that I think this circumvented the anti-wraparound vacuuming: a normal vacuum doesn't advance relfrozenxid anymore. We'll need to disable

Re: [HACKERS] Simple postgresql.conf wizard

of space (MB, GB, etc) for checkpoint_segments. I used to think of checkpoint_segments in terms of transaction rate and maximum tolerable recovery time but really if those are your constraints you're better off using checkpoint_timeout I think. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] Simple postgresql.conf wizard

the initdb output then? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Visibility map, partial vacuums

Gregory Stark [EMAIL PROTECTED] writes: Heikki Linnakangas [EMAIL PROTECTED] writes: Gregory Stark wrote: 1) Raise autovacuum_max_freeze_age to 400M or 800M. Having it at 200M just means unnecessary full table vacuums long before they accomplish anything. It allows you to truncate

Re: [HACKERS] Simple postgresql.conf wizard

I would be interested in looking at doing it if you want to send it to me. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Simple postgresql.conf wizard

Greg Smith [EMAIL PROTECTED] writes: On Wed, 3 Dec 2008, Gregory Stark wrote: It sure seems strange to me to have initdb which presumably is targeting a mixed system -- where it doesn't know for sure what workload will be run -- produce a different set of values than the tuner on the same

Re: [HACKERS] Simple postgresql.conf wizard

be? That and the unstated other question Is someone more likely to use partitions without reading the manual or not use partitions without reading the manual about the down-sides of constraint_exclusion (in the partitioning section) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com

Re: [HACKERS] Simple postgresql.conf wizard

Joshua D. Drake [EMAIL PROTECTED] writes: On Thu, 2008-12-04 at 00:11 +, Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I started to do this for you last week but got side-tracked. Do you have any time for this? I can do it if you have a script. Well, I can send you

Re: [HACKERS] Simple postgresql.conf wizard

Joshua D. Drake [EMAIL PROTECTED] writes: On Thu, 2008-12-04 at 00:11 +, Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I started to do this for you last week but got side-tracked. Do you have any time for this? I can do it if you have a script. So how big should

Re: [HACKERS] Simple postgresql.conf wizard

Greg Smith [EMAIL PROTECTED] writes: On Thu, 4 Dec 2008, Gregory Stark wrote: What I'm suggesting is that you shouldn't have to special case this. That you should expect whatever formulas you're using to produce the same values as initdb if they were run on the same machine initdb

Re: [HACKERS] Simple postgresql.conf wizard

Greg Smith [EMAIL PROTECTED] writes: On Thu, 4 Dec 2008, Gregory Stark wrote: Greg Smith [EMAIL PROTECTED] writes: Is it worse to suffer from additional query overhead if you're sloppy with the tuning tool, or to discover addition partitions didn't work as you expected? Surely that's

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

additional constraints on other columns even if they aren't the real partitioning key. So for example if you partition the invoice table by month once you close the books for a previous month you can add a constraint WHERE invoice_id 'xxx'. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] [PATCHES] GIN improvements

, inserts. I do like the idea of having the work fall to vacuum though. Perhaps we need some way for autovacuum to ask an access method what shape an index is in and whether it needs vacuuming? Or more likely a separate command from vacuum that specifically cleans up an index. -- Gregory Stark

Re: [HACKERS] Simple postgresql.conf wizard

think there are a lot of variables here. One is the distribution of the data. Your data sounds like it's reasonably evenly distributed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing

Re: [HACKERS] Enhancement to pg_dump

has advantages over DROP in that there is no window when the table does not exist and any existing references to the table from views or functions will continue to function. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services

Re: [HACKERS] Simple postgresql.conf wizard

columns which range from perfectly uniform to highly skewed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Enhancement to pg_dump

the table. It also means they can't proceed until all queries which have already started reading the table finish. DROP is still a lot heavier than TRUNCATE because it also has to drop (or search for and throw an error) anything else dependent on the table. triggers, views, etc. -- Gregory Stark

Re: [HACKERS] [bugfix] DISCARD ALL does not release advisory locks

points are pretty convincing. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Simple postgresql.conf wizard

Decibel! [EMAIL PROTECTED] writes: On Nov 25, 2008, at 7:06 PM, Gregory Stark wrote: The thought occurs to me that we're looking at this from the wrong side of the coin. I've never, ever seen query plan time pose a problem with Postgres, even without using prepared statements. I

Re: [HACKERS] Enhancement to pg_dump

exactly what the use case you're trying to cover here is but you should consider looking at TRUNCATE instead of DELETE if you're really deleting all the records in the table and can accept locking the table. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] Simple postgresql.conf wizard

, longer plan times -- and the benefits of having larger stats targets -- fewer columns which need raised stats targets. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers

Re: [HACKERS] Visibility map, partial vacuums

an xid you'll have to visit all the other pages covered by that visibility map page to see what the new value should be. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Visibility map, partial vacuums

Heikki Linnakangas [EMAIL PROTECTED] writes: Gregory Stark wrote: However I'm a bit puzzled how you could possibly maintain this frozenxid. As soon as you freeze an xid you'll have to visit all the other pages covered by that visibility map page to see what the new value should be. Right

Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.

it doesn't everywhere? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Error arguments in pl_exec.c

seems right to me - objections? ick. that's actually a security hole. Thankfully it's new code in cvs head. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] New bug

) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] New bug

Ibrar Ahmed [EMAIL PROTECTED] writes: Hi, It works fine on my machine Hm, a fresh checkout doesn't crash for me either any more. Hopefully it didn't just hide the problem because I stupidly just trashed the install that was exhibiting the problem. -- Gregory Stark EnterpriseDB

[HACKERS] Cool hack with recursive queries

ORDER BY IY, IX ) AS ZT GROUP BY IY ORDER BY IY -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Block-level CRC checks

Paul Schlie [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Gregory Stark wrote: However you still have a problem that someone could come along and set the hint bit between calculating the CRC and actually calling write. The double-buffering will solve that. Or simply require

Re: [HACKERS] Updated posix fadvise patch v19

else thinks it was nice to have scream now. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Updated posix fadvise patch v19

them and support isn't compiled in, but I'm not sure it's such a hot idea even for those. posix-fadvise-v20.patch.gz Description: Binary data -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers

Re: [HACKERS] Updated posix fadvise patch v19

about them: $ find . -name \*.[ch] -print0 | xargs -0 grep FIXME | wc -l 22 $ find . -name \*.[ch] -print0 | xargs -0 grep XXX | wc -l 485 $ find . -name \*.[ch] -print0 | xargs -0 grep TODO | wc -l 33 -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about

Re: [HACKERS] Block-level CRC checks

previously cared if hint-bits wern't set on WAL replay. Hum. Actually I think you're right. However you still have a problem that someone could come along and set the hint bit between calculating the CRC and actually calling write. -- Gregory Stark EnterpriseDB http

Re: [HACKERS] Visibility map, partial vacuums

would help with the temporary table problem on systems where the kernel is too aggressive about flushing file buffers or metadata. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] ORDER BY clause prevents UPDATE WHERE CURRENT OF

an index it would work. That this is tied to the nature of the plan does seem kind of unfortunate. I'm not sure the alternatives are very appealing though -- they would involve a lot of code to track a lot more information for queries that might never need it. -- Gregory Stark EnterpriseDB

Re: [HACKERS] Updated posix fadvise patch v19

for the zero-page case where we're not actually going to do I/O? Or am I missing where that will seg fault? Department of nitpicking: Will clean these up, they all look valid. I thought I did clean things up already -- I guess you should be happy you're looking at it *after* that cleanup :/ -- Gregory

<    1   2   3   4   5   6   7   8   9   10   >