Bruce Momjian writes:
> so the effect is:
>
> #define pg_snprintf libintl_snprintf
That's not how CPP works.
> In fact, in this example, the system complains about a missing X3 symbol:
>
> #define X1 X2
> #define X2 X3
In this case any occurrence of X1 replaced by X2 but th
Thanks to Andrew Dunstan, I found the cause of these link errors.
Andrew found this in libintl:
#undef snprintf
#define snprintf libintl_snprintf
extern int snprintf (char *, size_t, const char *, ...);
What is happening is that we do:
#define snprintf
Currently, in places like heap_drop_with_catalog, we issue a
FlushRelationBuffers() call followed by smgrscheduleunlink().
The latter doesn't actually do anything right away, but schedules
a file unlink to occur after transaction commit.
It strikes me that the FlushRelationBuffers call is unnecess
Tom Lane wrote:
That means we can go ahead with providing a GUC variable to make the
array size user-selectable. I was thinking of calling it either
"local_buffers" (in contrast to "shared_buffers") or "temp_buffers"
(to emphasize the fact that they're used for temporary tables).
Anyone have a pre
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Let me know what you come up with. Thanks for the help.
Hmph. On my FC3 machine, 7.4 is consistently faster than 7.3 in sorting
and grouping this data --- it's about 710 vs 960 msec. (This is on a P4
1.8GHz, presumably slower t
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Let me know what you come up with. Thanks for the help.
Hmph. On my FC3 machine, 7.4 is consistently faster than 7.3 in sorting
and grouping this data --- it's about 710 vs 960 msec. (This is on a P4
1.8GHz, presumably slower than your machines.)
On Sat, 19 Mar 2005, Tom Lane wrote:
That means we can go ahead with providing a GUC variable to make the
array size user-selectable. I was thinking of calling it either
"local_buffers" (in contrast to "shared_buffers") or "temp_buffers" (to
emphasize the fact that they're used for temporary ta
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Hm. What is the data like --- in particular, are the topic_ids unique
>> in the data processed by the sort?
>>
> Yes topic_ids are the primary key. Here is the nuke_bbtopics structure:
Hmmm ... because p.post_id has only a single value allowed by
The rest are pretty basic integers.
Hm. What is the data like --- in particular, are the topic_ids unique
in the data processed by the sort?
Yes topic_ids are the primary key. Here is the nuke_bbtopics structure:
Column| Type |
Modifiers
-
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The aggregation is a great deal worse as well. I suspect that for some
>> reason the comparison operations involved in the sorting and grouping
>> are much slower on the FC3 machine. What are the data types of the
>> leading sort
Well I definately did a initdb --no-locale
34 bin/initdb -D cdata --no-locale
But I didn't specify LC_COLLATE or LC_CTYPE explicitly.
I did set LANG="C" in /etc/sysconfig/i18n however.
Just to be specific...
show all from psql:
lc_collate | C
lc_ctype
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
If you look at the second line in each explain it is the sort that is
causing the grief.
The aggregation is a great deal worse as well. I suspect that for some
reason the comparison operations involved in the sorting and groupi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> If you look at the second line in each explain it is the sort that is
> causing the grief.
The aggregation is a great deal worse as well. I suspect that for some
reason the comparison operations involved in the sorting and grouping
are much slower
Specs:
7.3.6 machine Dual Athlon MP
2 GIG of ram,
4 Drive IDE (3ware) RAID 10
OS FC1 with 2.4 kernel
7.4.6 machine Dual Opteron MP (64bit PostgreSQL),
2 Gig of Ram
10 Drive RAID 10 with 128 Meg battery backed cache (3WARE).
OS FC3 x86_64 with 2.6 kernel
Essentials parameters:
7.3.6:
sha
We've had a TODO item for some time about allowing the user to set the
size of the local buffer array that's used for accessing temporary
tables. The holdup has been that localbuf.c used very unscalable
algorithms (like linear search) and so a large local buffer set would
have terrible performance
On Sat, 19 Mar 2005 11:05:39 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> > On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Why do you not define the problem as "when we decide a view is
> >> updateable and create the needed
On Sat, 19 Mar 2005 11:42:18 +, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-03-19 at 01:10 -0500, Jaime Casanova wrote:
> > On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > Jaime Casanova <[EMAIL PROTECTED]> writes:
> > > > ... but if we do INSERT INTO vfo
On Sat, 19 Mar 2005, Tom Lane wrote:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> > On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Why do you not define the problem as "when we decide a view is
> >> updateable and create the needed rules for it, also create default
Jaime Casanova <[EMAIL PROTECTED]> writes:
> On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Why do you not define the problem as "when we decide a view is
>> updateable and create the needed rules for it, also create default
>> values for it by copying up from the base t
On Sat, 2005-03-19 at 01:10 -0500, Jaime Casanova wrote:
> On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Jaime Casanova <[EMAIL PROTECTED]> writes:
> > > ... but if we do INSERT INTO vfoo(col2) values ('some_string) the
> > rewriter
> > > cann resolv the value for col1
20 matches
Mail list logo
