Josh Berkus <[EMAIL PROTECTED]> writes:
> I'm doing some analysis of PostgreSQL site traffic, and am being frequently
> hung up by the compile-time-fixed size of our regex cache (32 regexes, per
> MAX_CACHED_RES). Is there a reason why it would be hard to use work_mem
> or some other dynamicall
Coming to this thread a bit late as I've been out of email
connectivity for the past week...
On Tue, Jun 17, 2008 at 2:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> In any case, trying to define a module as a schema doesn't help at all
> to solve the hard problem, which is how to get this stuff to
On Tue, Jun 17, 2008 at 6:31 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Jeffrey Baker escribió:
> >> The table was originally created this way:
>
> > Okay, but was it created on 8.1 or was it already created on an older
> > version and restored? I don
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Jeffrey Baker escribió:
>> The table was originally created this way:
> Okay, but was it created on 8.1 or was it already created on an older
> version and restored? I don't see this behavior if I create it in 8.1
> -- the field is dumped as SERIAL, un
Folks,
I'm doing some analysis of PostgreSQL site traffic, and am being frequently
hung up by the compile-time-fixed size of our regex cache (32 regexes, per
MAX_CACHED_RES). Is there a reason why it would be hard to use work_mem
or some other dynamically changeable limit for regex caching?
Jorgen Austvik wrote:
Alvaro Herrera wrote:
Maybe, or maybe not. Do these platforms all have Perl?
gypsy_moth Solaris 8 SUN Studio 8 spar
If the moths don't have perl, we'll add it, no problem - don't let
that stop anything.
Of course they have perl - the buildfarm script is perl.
Alvaro Herrera wrote:
Maybe, or maybe not. Do these platforms all have Perl?
gypsy_moth Solaris 8 SUN Studio 8 spar
If the moths don't have perl, we'll add it, no problem - don't let that
stop anything.
(On a separate note, we have had some problems internally with DNS, so
some reporting
Jeffrey Baker escribió:
> The table was originally created this way:
>
> CREATE TABLE transaction
> (
> transaction_id SERIAL PRIMARY KEY,
> buyer_account_idINTEGER,
> seller_account_id INTEGER,
> dateDATE,
>
On Tue, Jun 17, 2008 at 2:43 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> Jeffrey Baker escribió:
> > On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > > "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > > > It is impossible to dump (with pg_dump -Ocx) and restore (wit
Jeffrey Baker escribió:
> On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > > It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
> > > database which contains sequences in any of 8.1, 8.2, or 8.3:
> >
> >
> > I definitely think it's worth it, even if it doesn't handle an
> > inline-compressed datum.
>
> Yeah. I'm not certain how much benefit we could get there anyway.
> If the datum isn't out-of-line then there's a small upper limit on how
> big it can be and hence a small upper limit on how long i
On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
> > database which contains sequences in any of 8.1, 8.2, or 8.3:
>
> I should think we would have heard ab
On Tue, Jun 17, 2008 at 01:29:56PM -0400, Tom Lane wrote:
> ...
> What I'm inclined to do is remove the two % operators, which don't seem
> likely to be performance-critical, and fill in the missing int2-vs-int8
> cases for the four basic arithmetic operators. But I could be talked
> into just nuk
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> But we can resolve that by ruling that the required lifetime is the same
>> as the value would have had if it'd really been palloc'd --- IOW, until
>> the memory context that was current at the time gets deleted or reset.
> Many support functions of GiS
But we can resolve that by ruling that the required lifetime is the same
as the value would have had if it'd really been palloc'd --- IOW, until
the memory context that was current at the time gets deleted or reset.
Many support functions of GiST/GIN live in very short memory context - only fo
"Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
> database which contains sequences in any of 8.1, 8.2, or 8.3:
I should think we would have heard about it before now if such a
sweeping claim were true.
What I suspect is that yo
There was a discussion back here:
http://archives.postgresql.org/pgsql-bugs/2008-01/msg00189.php
that came to the conclusion that cross-type operators are a bad idea
if they don't come in complete sets: if you don't have an exact match
to the input types, and there are multiple possible candidates,
It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
database which contains sequences in any of 8.1, 8.2, or 8.3:
[...]
--
-- Name: transaction_transaction_id_seq; Type: SEQUENCE SET; Schema:
mercado; Owner: prod
--
SELECT
pg_catalog.setval(pg_catalog.pg_get_serial_sequence('t
On Tue, 17 Jun 2008, Alvaro Herrera wrote:
Maybe, or maybe not. Do these platforms all have Perl?
Of course. They're all buildfarm clients and the buildfarm script is
perl.
Kris Jurka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> David Fetter wrote:
>> This is 2008, and it's silly to pretend we need to support this
>> "requirement" on systems where people are building Postgres.
> Maybe, or maybe not. Do these platforms all have Perl?
In this connection it might be worth pointi
David Fetter <[EMAIL PROTECTED]> writes:
> It's not quite that simple. Let's say you're *developing* a module.
> I don't see any way to play with it in the separate module proposal,
> where I *do* see a whole extra non-orthogonal feature where none is
> needed.
The claim that no new feature is ne
David Fetter wrote:
Yeah. Didn't we have this discussion already?
I don't know -- I skipped it. Sorry. Blame it on Dave Fetter :-P
Everything is my fault :)
You finally understand!
Joshua D. Drake
Cheers,
David.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Tue, Jun 17, 2008 at 11:00:31AM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Maybe what's needed here is just some more additional commands
> > > (i.e. "add this function to the module", "this module is
> > > dependent on this other module"
David Fetter wrote:
On Tue, Jun 17, 2008 at 10:19:59AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
Folks,
Well, it'll wind up with a build system that's documented a lot better
than it is :)
Is perl currently required to build from tarball? If not, you would
be placing an additional b
David Fetter wrote:
> That new version stamper calls out to sed, when perl is perfectly
> capable of doing the same work itself and not spawning 30 shells in
> the process.
That's great. Please send a patch to improve the stamper. (Are you
really worried about its performance, given that it run
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 developers feel welc
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Maybe what's needed here is just some more additional commands (i.e.
> > "add this function to the module", "this module is dependent on this
> > other module").
>
> Yeah. Didn't we have this discussion already?
I don't know -- I s
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe what's needed here is just some more additional commands (i.e.
> "add this function to the module", "this module is dependent on this
> other module").
Yeah. Didn't we have this discussion already?
regards, tom lane
--
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 developers feel welcome. I know peopl
David Fetter wrote:
> It's not quite that simple. Let's say you're *developing* a module.
> I don't see any way to play with it in the separate module proposal,
> where I *do* see a whole extra non-orthogonal feature where none is
> needed. No way to do optional submodules, either, and I'm sure
On Mon, Jun 16, 2008 at 09:43:37PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > David Fetter wrote:
> >> Maybe I'm missing something big, but I don't quite see what
> >> constitutes "proper" that doesn't involve the module's having at
> >> least one schema to itself.
>
>
David Fetter <[EMAIL PROTECTED]> writes:
> My proposal is a lot more modest, and doesn't conflict with the larger
> one. I'd like to move the above stuff to self-contained perl would
> help to make things more cross-platform and clean up, no offense to
> the fine authors, some pretty crufty code i
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 developers feel welcome. I know people are
working toward a cmake or other more cross-platform toolchain.
My p
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 developers feel welcome. I know people are
working toward a cmake or other more cross-platform toolchain.
My proposal is a lot more mod
Jeff <[EMAIL PROTECTED]> writes:
> On Jun 16, 2008, at 3:35 PM, Tom Lane wrote:
>> the result of decompressing an inline-compressed datum, because those
>> have no unique ID that could be used for a lookup key. This puts a
>> bit of a
> Wouldn't the tid fit this? or table oid + tid?
No. The kil
The example here
http://archives.postgresql.org/pgsql-novice/2008-06/msg00025.php
shows that we are failing to regenerate cached plans when a table
referenced by a regclass constant is removed. This is pretty minor
in the big scheme of things, but it's still annoying since there is
code in there t
Robert Treat wrote:
On Monday 16 June 2008 21:12:23 Andrew Dunstan wrote:
David Fetter wrote:
On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote:
I, too, would be happy to do the legwork on this one. I believe
we'd want to have both per-db and per-role settings fo
On Jun 16, 2008, at 3:35 PM, Tom Lane wrote:
to a cache entry rather than a freshly palloc'd value. The cache
lookup
key is the toast table OID plus value OID. Now pg_detoast_datum()
has no
...
the result of decompressing an inline-compressed datum, because
those have
no unique ID tha
On Monday 16 June 2008 21:12:23 Andrew Dunstan wrote:
> David Fetter wrote:
> > On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote:
> >>> I, too, would be happy to do the legwork on this one. I believe
> >>> we'd want to have both per-db and per-role settings for
> >>> search_path. Wh
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Hoo, nasty. Tcl_GetVar() is resetting interp->result.
According to the manual page that's only supposed to happen if the
TCL_LEAVE_ERR_MSG flag is used:
TCL_LEAVE_ERR_MSG
If an error is
40 matches
Mail list logo
