Attached are patches to fix the following compiler warnings that I see when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:601: warning: format not a string literal and no format
arguments
REL8_3_STABLE warnings:
utility.c: In function
Running the following against HEAD and REL8_3_6:
create table foo (a varchar(500));
create view bar as select case foo.a when '1' then 'foo' else 'bar' end as
fa from foo;
\d bar
Causes as assertion in the backend:
TRAP: FailedAssertion(!(Node*)(((list_head(((OpExpr *)
Hello,
I have multiple files with that have very similar distributions and I'm
seeing contention when concurrent COPY's are happening against a table with
a b-tree index on the timestamp column. Each file look something like the
following:
~4M rows with timestamp1
~4M rows with timestamp2
...
It doesn't look like it's related to autovacuum. I re-ran the test against
the two solaris boxes with autovacuum turned off and the results look about
the same.
8.3.7 - Solaris 10 11/06 s10x_u3wos_10 X86
real0m43.662s
user0m0.001s
sys 0m0.003s
real0m43.565s
user0m0.001s
sys
Hi Tom,
How much concern is there for the contention for use cases where the WAL
can't be bypassed?
Thanks, Alan
On Sun, Jun 21, 2009 at 10:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
The following copying 3M rows(each) into a seperate
On Mon, Jun 22, 2009 at 7:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alan Li a...@truviso.com writes:
How much concern is there for the contention for use cases where the WAL
can't be bypassed?
If you mean is something going to be done about it in 8.4, the
answer is no. This is a pre
Consider the following schema:
create table foo_archive (a int, b timestamp);
create index foo_archive_idx on foo_archive(b);
CREATE TABLE foo_archive_2007_01_01 (CONSTRAINT
foo_archive_2007_01_01_b_check CHECK (((b = '2007-01-01'::date) AND (b
'2007-01-02'::date INHERITS
On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark gsst...@mit.edu wrote:
Neat! I haven't read the patch yet but I have some questions.
Does this handle the case where some partitions have an index and
others don't? Ie. Does it just apply the regular optimization to each
partition and then slap on
On Sat, Jul 18, 2009 at 3:13 AM, Greg Stark gsst...@mit.edu wrote:
This part:
! /* only try to optimize children rel's */
! foreach (lc, root-append_rel_list)
! {
! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
!
!
On Sat, Jul 18, 2009 at 12:04 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Jul 18, 2009 at 6:35 PM, Alan Lia...@truviso.com wrote:
Yeah, are you running into the same issue as well? I tried to figure out
a
way around the O(n^2) behavior, but there were no existing direct
relationship
On Mon, Jul 20, 2009 at 12:29 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Jul 20, 2009 at 7:40 PM, Alan Lia...@truviso.com wrote:
Attached is an updated patch that removes the O(n^2) behavior and the
awkwardness of optimizing the seqscan path as the plan was about to be
created. Now,
I'm wondering how I can store word-level bigrams/trigrams in a tsvector
that I can query against. I was expecting the final query to match the
air and return the one tuple to me.
For instance:
postgres=# create table docs (a tsvector);
CREATE TABLE
postgres=# insert into docs (a) values
12 matches
Mail list logo
