|
May
14 |
|
awarded | Caucus |
|
Mar
18 |
|
awarded | Nice Answer |
|
Mar
11 |
|
comment |
PostgreSQL Equivalent of SQLServer's NoLock Hint @dezso: +1, but in 9.1 SERIALIZABLE was added, so the docs have been updated to say "...provides three isolation levels..." but is otherwise the same. |
|
Feb
27 |
|
awarded | Nice Answer |
|
Feb
23 |
|
answered | Case insensitivity in PostgreSQL |
|
Jan
11 |
|
answered | How can I execute non-query Stored Procedure in JDBC |
|
Jan
9 |
|
answered | Postgres Rails Select Distinct with Order |
|
Jan
9 |
|
comment |
Rebuilding system and tables, should I change primary key to int? Actually this answer directly contradicts mine. I'm saying you don't need the IDENTITY column at all and adding it at this point will only make life more complicated. |
|
Jan
9 |
|
comment |
Alphabetical ordering of database columns in a large rails application There is no way to do this in PostgreSQL without a dump/edit schema/restore of the table. This is by design, so there is no "but what if I..." to work around it. |
|
Jan
9 |
|
comment |
Is a surrogate key better than a natural key in this case @Songo: Funny that you say "I have a feeling that all natural keys are bad candidates". By definition, ALL natural keys are candidate keys. :) |
|
Jan
9 |
|
comment |
Is a surrogate key better than a natural key in this case @marc_s: That sample code appears to be PostgreSQL code, where TEXT is an alias for a VARCHAR with no upper limit. |
|
Jan
9 |
|
comment |
Is a surrogate key better than a natural key in this case Please remember: Even if you add a surrogate key, you still need to keep a UNIQUE, NOT NULL constraint on the original sets of columns in each table. A surrogate key is just that, a surrogate, and does NOT say anything about the data. You will still need to look up these records using the natural composite keys in order to get the surrogate key and the original constraint needs to remain to keep the data consistent. As a result, you will actually increase insert/update/delete costs by adding the surrogate key, not reduce them. |
|
Jan
9 |
|
comment |
Should a connection pooler be run on my database server or my app server? Massive. The cost of building up a new PostgreSQL connection is at least an order of magnitude higher than the designed-to-be-lightweight PgBouncer. For example: PostgreSQL validates and limits connections by IP/database/role using pg_hba.conf, whereas PgBouncer does not--it only validates via a local user/pass file (see system table pg_shadow for what is stored). It starts to add up. I've been doing PG for about 8 1/2 years now and when there's a performance issue, the first place I look is new connection churn. It's usually the culprit. |
|
Jan
8 |
|
comment |
Should a connection pooler be run on my database server or my app server? ...I'm implementing this shift right now in a very large project and expect to see impressive performance improvements over the client-side pools, even with the overhead for each new connection to PgBouncer. |
|
Jan
8 |
|
comment |
Should a connection pooler be run on my database server or my app server? There's a caveat to this: at the number of client pools increases, the benefits of having the server-side pool increases since each pool must keep some minimum number of persistent connections open or risk "thrashing" new connections on the server when exceeding average normal client pool size. This, in turn, results in a very large number of open connections at all times to the database server which are not free to maintain (even if idle). A server-side pool doesn't care home many clients there are an shares a smaller pool of connections across all of them... |
|
Jan
8 |
|
answered | PostgreSQL 9.0 implicit transactions not rolling back |
|
Jan
8 |
|
answered | How do you add new line breaks to a csv file using sql? |
|
Jan
8 |
|
comment |
Query for distinct values in postgres and php Why aren't you just running SELECT sd_code, stamp_type FROM stamp_den JOIN stamp_code USING (sd_code) ORDER BY sd_code, stamp_type and then building a map of sd_codes to lists of stamp_types and work with that? They way you appear to be doing things now will probably generate in an order of magnitude or more of network traffic via database trips. |
|
Jan
7 |
|
awarded | Good Answer |
|
Dec
29 |
|
comment |
"Zero" downtime and minimal space requirements for upgrade to PostgreSQL 9.2 Why can't you rebuild the binary? |
