2008/8/15 Tom Lane <[EMAIL PROTECTED]>:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> How is this supposed to interact with argument names ?
>
> Yeah, the real problem with this proposal is that it conscripts a syntax
> that we'll probably want to use in the future for argument-name-based
> parame
2008/8/14 Hannu Krosing <[EMAIL PROTECTED]>:
> On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote:
>> Hello
>>
>> I propose enhance current syntax that allows to specify label for any
>> function parameter:
>>
>> fcename(expr [as label], ...)
>> fcename(colname, ...)
>
> also fcename(localvar,
Hello all,
Here is the first pass at the unsigned data type I have been working on.
I am planning on adding these to the September 2008 commitfest wiki page.
The unsigned data type is not targeted for core, but for the uint PgFoundry
project.
The uint.c.gz file is the main source file for the ui
Hannu Krosing <[EMAIL PROTECTED]> writes:
> How is this supposed to interact with argument names ?
Yeah, the real problem with this proposal is that it conscripts a syntax
that we'll probably want to use in the future for argument-name-based
parameter matching. The proposed behavior is not nearly
Hello,
On Sat, 02 Aug 2008 18:37:25 +0200 Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
>
> > We could catch some simple problems at file load time, perhaps,
> > but those usually aren't the ones that cause trouble for people.
>
> It would catch thing
On Jul 29, 2008, at 9:12 PM, Robert Haas wrote:
Unfortunately, it looks to me like a fully general implementation of
this feature would be Really Hard, because a CREATE OR REPLACE VIEW
command, beyond attempting to add, drop, or retype columns, could also
attempt to reorder them. A cursory inspe
On Aug 12, 2008, at 2:26 AM, Dave Page wrote:
On Tue, Aug 12, 2008 at 4:13 AM, Bruce Momjian <[EMAIL PROTECTED]>
wrote:
So, ideally, if we do a plug-in system, I think we need some way
to have
these plugins be very easily installed, perhaps by choosing object
files
pre-compile by the build
On Aug 13, 2008, at 10:45 PM, Andrew Gierth wrote:
You could likely expose a difference using LIMIT 1 in the subselect,
but that doesn't tell us anything we didn't already know (which is
that yes, index scan is much faster than seqscan even for 1-block
tables, except in the rare case when neither
Jan Urbański wrote:
> Yeah, I got that idea, but then I thought the chances of touching the
> same element during binary search twice were very small. Especially now
> when the detoasting occurs only when we hit a text Datum that has the
> same length as the sought lexeme.
> Still, I can do
Alvaro Herrera wrote:
Jan Urbański wrote:
Heikki Linnakangas wrote:
Sounds like a plan. In (2), it's even better to detoast the values
lazily. For a typical one-word tsquery, the binary search will only
look at a small portion of the elements.
Hm, how can I do that? Toast is still a bit bla
Jan Urbański wrote:
> Heikki Linnakangas wrote:
>> Sounds like a plan. In (2), it's even better to detoast the values
>> lazily. For a typical one-word tsquery, the binary search will only
>> look at a small portion of the elements.
>
> Hm, how can I do that? Toast is still a bit black magic to
Looking at the list history, I see this has been discussed in the
past, but it has been long enough that perhaps it is time to revisit it.
It would appear from my own support queues, that one of the most
prevalent issues with PostgreSQL installations is not a functional
one, but an administ
On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote:
> Hello
>
> I propose enhance current syntax that allows to specify label for any
> function parameter:
>
> fcename(expr [as label], ...)
> fcename(colname, ...)
also fcename(localvar, ...) if called from another function ?
How is this sup
Jan Urbański wrote:
Heikki Linnakangas wrote:
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan.
Heikki Linnakangas wrote:
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan. In (2), it's even bet
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I can't yet *prove* that I can get better estimates
>> with the added info, but if not, that just means I need to rethink what
>> to pass down exactly.
> I'll see if I can do some testing here to confirm plan i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> My first attempt at a fix, which was simply swapping relfilenode for the
> TOAST tables (and its indexes) after the data has been copied, does not
> work, apparently because the TOAST pointers have the toast table ID
> embedded.
Ouch. Right.
> I wonde
Tom Lane wrote:
> I wrote:
> > Hmm, we could probably fix that if we made the cluster operation swap
> > the physical storage of the two toast tables, rather than swapping the
> > tables altogether. I agree it's not critical but it could be confusing.
>
> On second thought, I think it *could* lea
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> I can't yet *prove* that I can get better estimates
> with the added info, but if not, that just means I need to rethink
what
> to pass down exactly.
I'll see if I can do some testing here to confirm plan improvements
and check estimate accuracy. This i
On Fri, 2008-08-08 at 16:23 -0400, Tom Lane wrote:
> NOT IN is a lot trickier,
> for the same reason that typically trips up novices who try to use it:
> if any row of the subselect produces a NULL comparison result, then it
> is impossible for the NOT IN to result in TRUE, which means that it
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> OK, that sounds good. Are you also working on transforming NOT IN into
> different form? Or is that the same thing as (1)?
I'm not currently thinking about NOT IN. It could be transformed to
an antijoin if we could prove that no nulls are involved, but th
On Thu, 2008-08-14 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-08-13 at 23:12 -0400, Tom Lane wrote:
> >> We're just trying to provide better performance for certain common SQL
> >> idioms.
>
> > Sounds good, but can you explain how this will help?
>
Dmitry Koterov napsal(a):
Hello.
Here are these functions with detailed documentation:
http://en.dklab.ru/lib/dklab_postgresql_patch/
Added to next commit fest patch list.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
When upgrading, you use the pg_dump from the new version to
dump the old database. Then it can take care of incidental
changes during the process. I think that the mailing list
archives have articles on upgrading from v6.5. I do not think
that you can go straight from v6.5 to v8.3. You will almost
On Thu, Aug 14, 2008 at 9:58 AM, alexander lunyov <[EMAIL PROTECTED]> wrote:
> Hello everybody.
>
> We have a dusty old server, FreeBSD 3.3-RELEASE, PostgreSQL 6.5.3.
> I need to migrate four DBs from old server to new server (FreeBSD 6.2,
> PostgreSQL 8.3.1).
Just an FYI: I advised Alexander to p
Hello everybody.
We have a dusty old server, FreeBSD 3.3-RELEASE, PostgreSQL 6.5.3.
I need to migrate four DBs from old server to new server (FreeBSD 6.2,
PostgreSQL 8.3.1).
I've tried to do pg_dump on old server, transfer it to new one and do
`psql -f dumpfile dbname`. Well, no surprise, the
On Thu, 2008-08-14 at 09:27 -0400, Robert Haas wrote:
> I'm guessing it's this... looks pretty interesting even if not.
>
> http://optimizermagic.blogspot.com/2008/06/why-are-some-of-tables-in-my-query.html
Yes, thanks for copying it in.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQ
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2008-08-13 at 23:12 -0400, Tom Lane wrote:
>> We're just trying to provide better performance for certain common SQL
>> idioms.
> Sounds good, but can you explain how this will help?
1. Allowing optimization of EXISTS/NOT EXISTS as general-purpose
I'm guessing it's this... looks pretty interesting even if not.
http://optimizermagic.blogspot.com/2008/06/why-are-some-of-tables-in-my-query.html
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On Thu, Aug 14, 2008 at 9:02 AM, claudio lezcano <[EMAIL PROTECTED]> wrote:
> Thank you so much for the comments, he managed to advance the process of
> reconfiguring the directory compilation include Borland, however, has
> emerged another drawback, the problem has drawn up the following message:
Thank you so much for the comments, he managed to advance the process of
reconfiguring the directory compilation include Borland, however, has
emerged another drawback, the problem has drawn up the following message:
Error: Unresolved external '_pgwin32_safestat' referenced from C:\SOURCE
POSTGRES
Michael Holzman wrote:
On Wed, Aug 13, 2008 at 7:09 PM, Jaime Casanova wrote:
any move in this?
I did some changes to pgbench in February and sent them to Andrew. No
reaction has been got so far.
Oops. This completely got by me. I'll try to take a look at it RSN.
cheers
andre
Magnus Hagander wrote:
[about the ability to use different maps for ident auth, gss and krb
auth for example]
It wouldn't be very easy/clean to do that w/o breaking the existing
structure of pg_ident though, which makes me feel like using seperate
files is probably the way to go.
Heikki Linnakangas wrote:
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan. In (2), it's even bet
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2008-06-26 at 13:42 -0400, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > We can check for removal of a rel by...
>
> OT comment: I just found a blog about Oracle's optimizermagic, which is
> quite interesting. I notice there is
Jan Urbański <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> Speaking of which, a lot of time seems to be spent on detoasting. I'd like to
>> understand that a better. Where is the detoasting coming from?
>
> Hmm, maybe bttext_pattern_cmp does some detoasting? It calls
> PG_GETARG_TEXT_
On Wed, 2008-08-13 at 23:12 -0400, Tom Lane wrote:
> We're just trying to provide better performance for certain common SQL
> idioms.
Sounds good, but can you explain how this will help? Not questioning it,
just after more information about it.
I'm half way through join removal patch, so this w
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan. In (2), it's even better to detoast the values
On Thu, 2008-06-26 at 13:42 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > We can check for removal of a rel by...
OT comment: I just found a blog about Oracle's optimizermagic, which is
quite interesting. I notice there is a blog there about join removal,
posted about 12 ho
Hello
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
I would to allow same behave of custom functions like xmlforest function:
postgres=# select xmlforest(a) from foo;
xmlforest
---
10
(1 ro
Heikki Linnakangas wrote:
Jan Urbański wrote:
Not good... Shall I try sorting pg_statistics arrays on text values
instead of frequencies?
Yeah, I'd go with that. If you only do it for the new
STATISTIC_KIND_MCV_ELEMENT statistics, you shouldn't need to change any
other code.
OK, will do.
On Wed, 2008-08-13 at 21:30 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It seems like we'll want to do it somehow. Perhaps the cleanest way is
> >> to incorporate toast-table settings in the reloptions of the parent
> >> table. Otherwise dump/relo
Jan Urbański wrote:
Not good... Shall I try sorting pg_statistics arrays on text values
instead of frequencies?
Yeah, I'd go with that. If you only do it for the new
STATISTIC_KIND_MCV_ELEMENT statistics, you shouldn't need to change any
other code.
Hmm. There has been discussion on raising
43 matches
Mail list logo
