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
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 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%
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
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
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 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
"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 <[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
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:
> 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
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
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
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
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.
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:
> 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,
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
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
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
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
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
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
23 matches
Mail list logo
