Heikki Linnakangas wrote:
Jan Urbański wrote:
26763 3.5451 AllocSetCheck
Make sure you disable assertions before profiling.
Awww, darn. OK, here goes another set of results, without casserts this
time.
=== CVS HEAD ===
number of clients: 10
number of transactions per client: 10
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
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/reload is gonna
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.
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
---
a10/a
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 hours
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 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
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_PP(),
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 a blog there
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
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.
Actually, I
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
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
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:
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:
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 joins.
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
PostgreSQL
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,
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 post
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
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
--
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?
1. Allowing
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 that
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
does
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 is only
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* lead to a
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 wonder if
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 improvements
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
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.
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 supposed
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
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 me...
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
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 it
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
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 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
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 things like
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
41 matches
Mail list logo
