Bruce Momjian wrote:
David Fetter wrote:
On Tue, Jun 17, 2008 at 10:19:59AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
Folks,
I've noticed that a big hunk of our build system has gratuitous
dependencies on some variety of shell and on tools like sed, none
of which makes
David Fetter wrote:
> On Tue, Jun 17, 2008 at 10:19:59AM -0400, Andrew Dunstan wrote:
> > David Fetter wrote:
> >> Folks,
> >>
> >> I've noticed that a big hunk of our build system has gratuitous
> >> dependencies on some variety of shell and on tools like sed, none
> >> of which makes Windows deve
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I keep seeing these files show up in the source tree in a VPATH build:
> ? src/interfaces/ecpg/compatlib/libecpg_compatddll.def
> ? src/interfaces/ecpg/ecpglib/libecpgddll.def
> ? src/interfaces/ecpg/pgtypeslib/libpgtypesddll.def
> I am not sure if the
Hi,
I keep seeing these files show up in the source tree in a VPATH build:
? src/interfaces/ecpg/compatlib/libecpg_compatddll.def
? src/interfaces/ecpg/ecpglib/libecpgddll.def
? src/interfaces/ecpg/pgtypeslib/libpgtypesddll.def
I am not sure if these should stay on the source dir (i.e. are they
On Wed, 2008-06-18 at 14:53 +0100, Simon Riggs wrote:
> There is one minor strangeness in the patch, which is the change of
> initdb's command order when "vacuuming database template1". With the
> previous ordering of ANALYZE; VACUUM FULL; VACUUM; the flexible hint bit
> setting of the ANALYZE on
Tom,
I'm not excited about it either, but I think if we're going to make
this adjustable it does need its own knob. I can easily believe
that a large list of precompiled GUCs could be counterproductive
given a workload where you don't get much reuse, so I don't want
the list size going to the m
Josh Berkus <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. Well, I still don't want to tie it to work_mem; how do you feel
>> about a new GUC to determine the max number of cached REs?
> Yeah. You know me, I was just trying to avoid having more GUCs.
I'm not excited about it either, but
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Having said that, I'm not sure it'd help your problem. If your query is
using more than 32 regexes concurrently, it likely is using $BIGNUM
regexes concurrently. How do we fix that?
Hmmm. I think there's a lot of ground between 32 and
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Having said that, I'm not sure it'd help your problem. If your query is
>> using more than 32 regexes concurrently, it likely is using $BIGNUM
>> regexes concurrently. How do we fix that?
> Hmmm. I think there's a lot of ground between 32 and $BIGNUM.
Dimitry,
I stated details of proposal on page 2-13, 67-75 of pdf-document
http://sql50.euro.ru/sql5.16.4.pdf , and i ask to implement it.
All my proposals are public domain.
I'm confused. You're planning to develop this, or you're looking for
someone else to?
--Josh
--
Sent via pgsql-hack
Translators: refer to
http://archives.postgresql.org/message-id/27688.1213803578%40sss.pgh.pa.us
Tom Lane wrote:
> This should be a simple, easily tested patch, and I am tempted to
> propose back-patching it into 8.3, on the grounds that people need
> help now --- by the time 8.4 is out they'll a
Tom,
> Having said that, I'm not sure it'd help your problem. If your query is
> using more than 32 regexes concurrently, it likely is using $BIGNUM
> regexes concurrently. How do we fix that?
Hmmm. I think there's a lot of ground between 32 and $BIGNUM. For example,
where I'm hitting a wall
Simon Riggs <[EMAIL PROTECTED]> writes:
> Agreed. Yet I'm thinking that a more coherent approach to optimising the
> tuple memory usage in the executor tree might be better than the special
> cases we seem to have in various places. I don't know what that is, or
> even if its possible though.
Yeah
I'm not totally sure that bug #4253 reflects a problem in the user's
text search stopword files, but I'm suspicious. If I deliberately
introduce an encoding error into italian.stop, I get
regression=# select to_tsvector('italian','prova');
ERROR: invalid byte sequence for encoding "UTF8": 0xc30a
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-06-17 at 13:29 -0400, Tom Lane wrote:
>> What I'm inclined to do is remove the two % operators, which don't
>> seem likely to be performance-critical
> Can you discuss what you see as the benefit or trade-offs for doing
> that? Removing things
"Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> The two tables are defined the same way, but one of them gets dumped with a
> SERIAL declaration and the other gets dumped with a DEFAULT nextval().
> Is it possible that pg_dump became confused if transaction was renamed
> transaction_backup and then
Simon Riggs wrote:
> When running a VACUUM command we always dirty the block when setting
> hint bits, for a number of reasons:
> * VACUUM FULL expects all hint bits to be set prior to moving tuples
> * Setting all hint bits allows us to truncate the clog
> * it forces the VACUUM to write out its
On Wed, 2008-06-18 at 09:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > You've not covered the idea that we just alter the execution so we just
> > detoast once.
>
> That's because I already considered and rejected that idea. There's
> no very good place to do it. See t
Simon Riggs <[EMAIL PROTECTED]> writes:
> You've not covered the idea that we just alter the execution so we just
> detoast once.
That's because I already considered and rejected that idea. There's
no very good place to do it. See thread on postgis-devel:
http://postgis.refractions.net/pipermai
Greg Smith wrote:
> On Thu, 5 Jun 2008, Magnus Hagander wrote:
>
>> We really need a "proper API" for it, and the stuff in pgAdmin isn't
>> even enough to base one on.
>
> I would be curious to hear your opinion on whether the GUC overhaul
> discussed in this thread is a useful precursor to build
On Mon, 2008-06-16 at 15:35 -0400, Tom Lane wrote:
> Recent discussions with the PostGIS hackers led me to think about ways
> to reduce overhead when the same TOAST value is repeatedly detoasted.
> In the example shown here
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php
> 90%
Good day,
Progress in office technologies stopped, and it has occurred because user
himself can not map arbitrary 3-dimensional composition _into_ a window.
In the same time, it's possible to keep composition in Postgres, to extract by
operator 'select', and to transfer got binary data without tra
On Tue, 2008-06-17 at 13:29 -0400, Tom Lane wrote:
> What I'm inclined to do is remove the two % operators, which don't
> seem likely to be performance-critical
Can you discuss what you see as the benefit or trade-offs for doing
that? Removing things tends to have major potential for annoying us
23 matches
Mail list logo
