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 scan_
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 t
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: pgsql-hackers@pos
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
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 arou
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
> una
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, bu
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 exec
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
vi
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
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 no
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 d
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!
>
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 co
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 pl
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 w
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 ?
>
>
>
>
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
som
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:
http://www.reuters.com/article/oddlyEnoughNews/idUSN2
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 store
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
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 mi
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.
http://search
"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 use
"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
"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
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
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
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Fix a portability bug (ye olde not casting a 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 bu
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 something
"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 avo
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 inte
32 matches
Mail list logo
