Andrew Dunstan writes:
> Tom Lane wrote:
>> Andrew Dunstan writes:
>>> I think it would need to be benchmarked. My faint recollection is that
>>> the re-entrant lexers are slower.
>>
>> The flex documentation states in so many words:
>>The option `--reentrant' does not affect the performanc
On Wed, Jul 8, 2009 at 1:11 AM, Joshua Tolley wrote:
> On Thu, Jul 02, 2009 at 03:42:56PM +0100, Dave Page wrote:
>> On Thu, Jul 2, 2009 at 3:22 PM, Joshua Tolley wrote:
>> > On Thu, Jul 02, 2009 at 08:41:27AM +0100, Dave Page wrote:
>> >> As far as I'm aware, there's been no code
>> >> review yet
Josh Berkus wrote:
Hmmm, how about this?
"The current policy of the PostgreSQL community is to stop providing
minor versions (patches or updates) of PostgreSQL five years after a
version of PostgreSQL is released.
I think this is putting it the wrong way round. We should say that the
gen
Hmmm, how about this?
"The current policy of the PostgreSQL community is to stop providing
minor versions (patches or updates) of PostgreSQL five years after a
version of PostgreSQL is released. In general, users can expect to
continue to be able to get community updates for five years.
How
On 7/11/09 3:50 AM, Greg Stark wrote:
Hm. Actually maybe not. What if the index is an expression index and
the expression includes a function which does an SQL operation? I'm
not sure how realistic that is since to be a danger that SQL operation
would have to be an insert, update, or delete which
On Sat, 2009-07-11 at 19:06 -0400, Tom Lane wrote:
> > Is it possible to re-add amgettuple to GIN, and just set the cost high
> We wouldn't have deleted it if it were practical to make it work.
Can you elaborate a little?
Following the thread, I see:
http://archives.postgresql.org/pgsql-hackers
Jeff Davis writes:
> Is it possible to re-add amgettuple to GIN, and just set the cost high
> so it's not chosen by the planner? Or is there some reason this is
> fundamentally a bad idea (or won't work at all)?
We wouldn't have deleted it if it were practical to make it work.
Right now this patch does not support GIN because GIN doesn't support
amgettuple.
It could be made to support GIN by doing a bitmap index scan, manually
fetching the next tuple (or, if it's lossy, the next one on the page),
checking it against the snapshot, and then rechecking it to make sure it
s
On Sat, Jul 11, 2009 at 03:43:02PM -0400, Andrew Dunstan wrote:
> >Mac OSX 10.4.11 - GNU Bison version 1.28
>
> We have not supported any version less than 1.875 for as long as I
> have been working on Postgres.
We switched to 1.50 at some point in 2002 because we had to, ecpg had reached
the lim
Shane Ambler wrote:
The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD
and Solaris. What version of Bison are they shipping with?
Mac OSX 10.4.11 - GNU Bison version 1.28
We have not supported any version less than 1.875 for as long as I have
been working on Postgres.
On 7/11/09 12:24 PM, Shane Ambler wrote:
The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD
and Solaris. What version of Bison are they shipping with?
Mac OSX 10.4.11 - GNU Bison version 1.28
Hmmm, given the number of other OSS things which won't install on 10.4
(like Firefox
Hi,
Well, best to write this way:
Goal : query splitted to base elements
Result : xml response from server
Client : select pg_reparse_query();
Target: 8.4 version
How : modification of ruleutiles.c
Not done : UNION etc.
Not done : as builtin function, I don't know how to do it )))
The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and
Solaris. What version of Bison are they shipping with?
Mac OSX 10.4.11 - GNU Bison version 1.28
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andres Freund writes:
> I just realized doing it in a naive way (in geqo()) causes the state to be
> reset multiple times during one query- at every invocation of
> make_rel_from_joinlist.
> Does anybody see a problem with that?
I think that's probably what we want. Otherwise, you'd have a si
On Saturday 11 July 2009 18:23:59 Tom Lane wrote:
> On reflection I think the best user API is probably a "geqo_seed" GUC in
> the range 0 to 1, and have GEQO always reset its seed to that value at
> start of a planning cycle. This ensures plan stability, and if you need
> to experiment with alter
On Sat, Jul 11, 2009 at 12:23:59PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > The only question I have is, whether random_r or similar is available on
> > enough platforms... Has anybody an idea about this?
> > On most unixoid system one could just wrap erand48() if random_r is not
> > a
Andres Freund writes:
> On Saturday 11 July 2009 18:23:59 Tom Lane wrote:
>> So far as I can find in a quick google search, neither of these families
>> of functions exist on Windows :-(. So I think maybe the best approach
>> is the second one --- we could implement a port/ module that provides a
Hi,
On Saturday 11 July 2009 18:23:59 Tom Lane wrote:
> Andres Freund writes:
> > The only question I have is, whether random_r or similar is available on
> > enough platforms... Has anybody an idea about this?
> > On most unixoid system one could just wrap erand48() if random_r is not
> > availa
Andres Freund writes:
> The only question I have is, whether random_r or similar is available on
> enough platforms... Has anybody an idea about this?
> On most unixoid system one could just wrap erand48() if random_r is not
> available.
> Windows?
random_r() isn't in the Single Unix Spec AFAIC
Greg Stark writes:
> I wonder whether an earlier more general proposal could have some
> leverage here though: some way to indicate that the transaction has
> taken all the locks it plans to take already. This was originally
> proposed as a way for vacuum to know it can ignore the snapshots of a
>
On Wednesday 08 July 2009 23:46:02 Tom Lane wrote:
> "Kevin Grittner" writes:
> > For a moment it seemed logical to suggest a session GUC for the seed,
> > so if you got a bad plan you could keep rolling the dice until you got
> > one you liked; but my right-brain kept sending shivers down my spin
On Jul 11, 2009, at 6:50 AM, Greg Stark wrote:
On Sat, Jul 11, 2009 at 6:17 AM, Theo Schlossnagle
wrote:
On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle writes:
I would think it would be txns that would be reading that table,
but
I'm thinking it is a bit to aggressive
On Sat, Jul 11, 2009 at 6:17 AM, Theo Schlossnagle wrote:
>
>
> On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
>
>> Theo Schlossnagle writes:
>>>
>>> I would think it would be txns that would be reading that table, but
>>> I'm thinking it is a bit to aggressive. Am I reading the code wrong
>>> the
On Wednesday 08 July 2009 01:07:08 Tom Lane wrote:
> Peter Eisentraut writes:
> > Here is a first cut at a new hex bytea input and output format. Example:
> > ...
> > SET bytea_output_hex = true;
> >
> > Should the configuration parameter be a boolean or an enum, opening
> > possibilities for oth
24 matches
Mail list logo
