I think the change to the hash functions needs to be called out in the release
notes.
If anyone stored any results of hashintN, hashfloat8, etc in their database or
outside the database those results will have changed. It's fairly unlikely but
there could be someone out there doing that.
No
Tom Lane [EMAIL PROTECTED] writes:
Log Message:
---
Fix up text concatenation so that it accepts all the reasonable cases that
were accepted by prior Postgres releases. This takes care of the loose end
left by the preceding patch to downgrade implicit casts-to-text. To avoid
Hi,
Gregory Stark wrote:
Perhaps if you're doing some form of replication between different
architectures you might want to use binary representation for your transfers.
Or if you're doing something in a PL language like compressing or bundling up
multiple data in a container format or
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Fix a portability bug (ye olde not casting a ctype.h argument to
unsigned char). Fortunately we still have buildfarm machines that
will flag this. Seems to be new in CVS HEAD, so no backpatch.
Should we add
Markus Schiltknecht [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Perhaps if you're doing some form of replication between different
architectures you might want to use binary representation for your transfers.
Or if you're doing something in a PL language like compressing or bundling up
Hi,
Is there a way to have access to PostgreSQL query plan and/or predicates
inside a function using spi (or any other way)?
For example:
explain select * from my_func() as (code int, name varchar) where name like
'a%';
QUERY PLAN
Cristiano Duarte [EMAIL PROTECTED] writes:
Is there a way to have access to PostgreSQL query plan and/or predicates
inside a function using spi (or any other way)?
No.
regards, tom lane
---(end of broadcast)---
TIP 2:
Tom Lane [EMAIL PROTECTED] writes:
Log Message:
---
Silence Solaris compiler warnings, per buildfarm.
This one was also lost in the tsearch merge.
The second half from query_support.c seems to be in tsquery_op.c now but isn't
relevant because it relates to PG_FUNCTION_INFO_V1().
Tom Lane [EMAIL PROTECTED] writes:
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible. There might be some excuse for
doing this within a single architecture, but I can't get very excited
about it ...
Well they're not very useful for
hi,
I use postgresql 8.2 and I cant see database diagram on pgAdmin III, I think
it can be . it is there , isnt it ?
Got a little couch potato?
Check out fun summer activities for kids.
Hello Tom,
Tom Lane wrote:
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible.
Can you elaborate on this? AFAICT the send/recv functions use network
byte ordering. What are the other problems between different architectures?
There
Markus Schiltknecht [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible.
Can you elaborate on this? AFAICT the send/recv functions use network
byte ordering. What are the other problems between
2007/9/17, Tom Lane [EMAIL PROTECTED]:
Cristiano Duarte [EMAIL PROTECTED] writes:
Is there a way to have access to PostgreSQL query plan and/or predicates
inside a function using spi (or any other way)?
No.
Hi Tom,
No means: there is no way since the query plan is stored in a
Just for information. Venezuela is going to have new timezone change
(30minutes shift) on this weekend. This change is not yet integrated in
the last version in Olson database. (Original announcement said it
happens on 1.1.2008)
More info:
Hi,
Tom Lane wrote:
Well, you're probably fine with integers and text, but beyond that it
gets a bit more dicey. I wouldn't want to assume that floats are
compatible across any random pair of architectures, and in the more
complex datatypes (such as arrays or geometric types) there might be
Wrong list. Try asking on the pgAdmin3 list, or maybe pgsql-general.
Andrew
On 9/16/07, Eretna Evrengizid [EMAIL PROTECTED] wrote:
hi,
I use postgresql 8.2 and I cant see database diagram on pgAdmin III, I
think it can be . it is there , isnt it ?
--
Be
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I wonder why all messages going through errcontext function are not
translatable.
I don't think it's errcontext's fault. The PLs in general don't have
any translation coverage. This seems a bit difficult to fix: I don't
think
Cristiano Duarte wrote:
2007/9/17, Tom Lane [EMAIL PROTECTED]:
Cristiano Duarte [EMAIL PROTECTED] writes:
Is there a way to have access to PostgreSQL query plan and/or predicates
inside a function using spi (or any other way)?
No.
Hi Tom,
No means: there is no way since the query plan is
Hello,
I am a graduate student of computer science and I have been looking at
PostgreSQL for my master's thesis work.
I am looking into implementing raw device I/O for large objects into
PostgreSQL (maybe for all storage, I'm not sure which would be
easier/better). I am extremely new to the
On 9/17/07, Georgi Chulkov [EMAIL PROTECTED] wrote:
Could someone please point me to the right places to look at, and how/where to
get started? Would such a development be useful at all? Is anyone working on
anything related?
Any feedback / information would be highly appreciated!
I have finished a first review pass over all of the HOT patch
(updated code is posted on -patches). I haven't found any showstoppers,
but there seem still several areas that need discussion:
* The patch makes undocumented changes that cause autovacuum's decisions
to be driven by total estimated
Tom Lane wrote:
* We also need to think harder about when to invoke the page pruning
code. As the patch stands, if you set a breakpoint at
heap_page_prune_opt it'll seem to be hit constantly (eg, once for every
system catalog probe), which seems uselessly often. And yet it also
seems not
Georgi Chulkov [EMAIL PROTECTED] writes:
I am looking into implementing raw device I/O for large objects into
PostgreSQL (maybe for all storage, I'm not sure which would be
easier/better).
We've heard this idea proposed before, and it's been shot down as a poor
use of development effort
On Sep 17, 2007, at 19:46 , Florian G. Pflug wrote:
Thats only holds true for functions in languages other than pl/sql
(Which is
*not* the same as pl/pgsql) - SQL functions can be inlined by the
executor, and
then are subject to the usual optimizations. (So they essentially
behave like
Bruce Momjian [EMAIL PROTECTED] writes:
If we only prune on an update (or insert) why not just do prune every
time?
The problem is you can't prune anymore once you have existing pin on the
target page. I'd really like to get around that, but so far it seems
unacceptably fragile --- the
Michael Glaesemann [EMAIL PROTECTED] writes:
AIUI, the stress is on the *can*, with a meaning of may, right? Not
all SQL functions can be inlined.
In particular, I think the OP was thinking of a function returning set,
which we currently don't inline at all. I believe this is doable, but
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If we only prune on an update (or insert) why not just do prune every
time?
The problem is you can't prune anymore once you have existing pin on the
target page. I'd really like to get around that, but so far it seems
unacceptably
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The problem is you can't prune anymore once you have existing pin on the
target page. I'd really like to get around that, but so far it seems
unacceptably fragile --- the executor really doesn't expect tuples to
get moved around
Hi,
We've heard this idea proposed before, and it's been shot down as a poor
use of development effort every time. Check the archives for previous
threads, but the basic argument goes like this: when Oracle et al did
that twenty years ago, it was a good idea because (1) operating systems
Index organized tables would do this and it would be a generic capability.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Georgi Chulkov [mailto:[EMAIL PROTECTED]
Sent: Monday, September 17, 2007 11:50 PM Eastern Standard Time
To: Tom Lane
Cc:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The problem is you can't prune anymore once you have existing pin on the
target page. I'd really like to get around that, but so far it seems
unacceptably fragile --- the executor really doesn't expect tuples to
On Sat, 8 Sep 2007, Greg Smith wrote:
Here's the results I got when I pushed the time down significantly from the
defaults
info | set | tps | cleaner_pct
---+-+--+-
jit multiplier=1.0
32 matches
Mail list logo
