Josh Berkus <[EMAIL PROTECTED]> writes:
> Tom,
>> The problem is that this is not a back-patchable
>> answer, because changing the hash functions would corrupt existing hash
>> indexes.
> Does anyone *use* hash indexes?
We get bug reports on 'em, so yes ...
regards, tom
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The best idea I can come up with for the back branches is
> to make ExecHashGetBucketAndBatch do hash_any internally, say
hashany of a 4-byte value degenerates to pretty much just a call to mix().
Perhaps we should just expose a hash12() that takes three
Tom,
> The problem is that this is not a back-patchable
answer, because changing the hash functions would corrupt existing hash
indexes.
Does anyone *use* hash indexes?
Comments, better ideas?
I was just talking to Luke today and he said they had a considerable
amount of cleanup on hash
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> If we apply Heikki's idea of advancing OldestXmin, I think what we
>>> should do is grab the value from pgstats when vacuum starts, and each
>>> time we're going to advance OldestXmin, gra
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Our documentation says
> | analyze threshold = analyze base threshold
> | + analyze scale factor * number of tuples
> | is compared to the total number of tuples inserted, updated, or deleted
> | since the last ANALYZE.
> but de
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > If we apply Heikki's idea of advancing OldestXmin, I think what we
> > should do is grab the value from pgstats when vacuum starts, and each
> > time we're going to advance OldestXmin, grab the value from pgstats
> > again; accumulate
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If we apply Heikki's idea of advancing OldestXmin, I think what we
> should do is grab the value from pgstats when vacuum starts, and each
> time we're going to advance OldestXmin, grab the value from pgstats
> again; accumulate the differences from the
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>
> > It may boil down to whether we would like the identity
> > n_live_tup = n_tup_ins - n_tup_del
> > to continue to hold, or the similar one for n_dead_tup. The problem
> > basically is that pgstats is computing n_live_tup and n
Bruce Momjian wrote:
Joshua D. Drake wrote:
Joshua D. Drake wrote:
Hello,
I am currently writing some curriculum on managing IO with PostgreSQL
and I keep running into the parameter checkpolint_timeout.
*cough* checkpoint_timeout
This seems to
be incorrect as it is not really a timeout a
I was idly thinking about Joseph Shraibman's problem here:
http://archives.postgresql.org/pgsql-general/2007-05/msg01011.php
in which a large hash join seemed to be blowing out memory.
By chance I tried the following test case:
js=# create table ml (jid int);
CREATE TABLE
js=# insert into ml selec
Tom Lane wrote:
> It may boil down to whether we would like the identity
> n_live_tup = n_tup_ins - n_tup_del
> to continue to hold, or the similar one for n_dead_tup. The problem
> basically is that pgstats is computing n_live_tup and n_dead_tup
> using those identities rather than by trac
On 5/31/07, CAJ CAJ <[EMAIL PROTECTED]> wrote:
> Can it me made to return an integer like most UNIX commands do? This
> helps
> > immensely when writing shell scripts.
>
> Don't they do that already? If not, that's a bug quite independent of
> Peter's cosmetic concern.
Ah, I just tested it.
Hello,
-> INDEX Scan USING tickets_q1_import6 ON tickets_q1 tickets
(cost=0.00..2.06 rows=1 width=0)
-> INDEX Scan USING tickets_q1_import6 ON tickets_q1 tickets
(cost=0.00..2.06 rows=1 width=0)
Note that those are actually *2* different tables in different schemas.
It would be great if it
On Thu, May 31, 2007 at 09:58:27AM -0400, Werner Echezuria wrote:
> Hello, (First of all, sorry for my english),
>
> I'm in a project that involves including sqlf sentences to make postgres
> understand the fuzzy querys, i mean, make people to create fuzzy
> predicates, these are words like fat,
Tom,
> I've applied a patch that fixes this case, but I'm not yet 100%
> convinced that there are no other cases where it'll prevent matching
> things that should match. Please test.
Will do. We're having trouble building from CVS on the TPCE test rig, so
it'll wait for tommorrow's snapshot.
"CAJ CAJ" <[EMAIL PROTECTED]> writes:
> Can it me made to return an integer like most UNIX commands do? This helps
> immensely when writing shell scripts.
Don't they do that already? If not, that's a bug quite independent of
Peter's cosmetic concern.
regards, tom lane
--
On 5/31/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
The messages output by the "scripts" always seemed unnecessary to me, e.g
.,
$ createdb foo
CREATE DATABASE
A Unix program (hi Magnus) shouldn't need to say anything if the requested
action succeeded.
I believe the history of this output
Josh Berkus <[EMAIL PROTECTED]> writes:
>> It does the right thing if t_s_symb is declared as text instead of
>> varchar. When it's varchar, even setting enable_sort off won't make
>> it pick the right plan, which suggests that it fails to recognize that
>> the index can match the query's ORDER BY
Zoltan Boszormenyi wrote:
Also: to the extent that the application is willing to deal with a
Postgres-specific inet/cidr representation (which, in the end, is
what this would be) it can do that *today* using binary output format.
So I'm still not seeing an argument for exposing a cast to bytea.
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Bruce Momjian írta:
What is the use case for such a cast?
The application doesn't want to parse the textual IP address
when all the parsing and checking intelligence is already there
in the inet/cidr type checks.
Mathias Palm wrote:
Hi,
I have found a problem by using timestamp datatyp in postgresql. The
minimum value should be '4713-11-24 00:00:00 BC' but it's possible to
use '4714-11-24 00:00:00 BC'. I have found the problem by using a binary
cursor where I get the value as double. Is this the right li
Hi,
I have found a problem by using timestamp datatyp in postgresql. The
minimum value should be '4713-11-24 00:00:00 BC' but it's possible to
use '4714-11-24 00:00:00 BC'. I have found the problem by using a binary
cursor where I get the value as double. Is this the right list for
posting this pr
Grant Finnemore <[EMAIL PROTECTED]> writes:
> The query with no EXPLAIN (ANALYSE) completes fine.
> The query with EXPLAIN ANALYSE completes fine.
> However, with just EXPLAIN (no ANALYSE)
Need a complete test case please, not just the query. All I get here is
ERROR: relation "tagged_asset" does
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Bruce Momjian írta:
>> What is the use case for such a cast?
> The application doesn't want to parse the textual IP address
> when all the parsing and checking intelligence is already there
> in the inet/cidr type checks.
This presumes exactly the
Hello, (First of all, sorry for my english),
I'm in a project that involves including sqlf sentences to make postgres
understand the fuzzy querys, i mean, make people to create fuzzy
predicates, these are words like fat, tall, young, old, in an sql sentence.
I guess the first step is complete. T
> I tested EXTERN_TUPLES_PER_PAGE for values 4(default), 2, and 1:
>
> 4 15.596
> 2 15.197
> 1 14.6
>
> which is basically a 3% decrease from 4->2 and 2->1. The
> test script and result are here:
>
> http://momjian.us/expire/TOAST2/
>
> shared_buffer
The messages output by the "scripts" always seemed unnecessary to me, e.g.,
$ createdb foo
CREATE DATABASE
A Unix program (hi Magnus) shouldn't need to say anything if the requested
action succeeded.
I believe the history of this output is actually that these scripts simply
used to call psql a
Rodrigo Sakai wrote:
> Basically, the data type is a composition of two timestamps, like:
> (timestamp, timestamp) and it is called 'period'. So, almost everything is
> fine. Data type is ok, operators are ok, but the index doesn't work fine.
Does type tinterval not suit you? It is not very we
Grant Finnemore napsal(a):
CrashReporter trace:
Date/Time: 2007-05-31 10:21:39.285 +0200
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4
Command: postmaster
Path:./bin/postmaster
Parent: postmaster [23091]
Version: ??? (???)
PID:23096
Thread: 0
Exception: EXC_BAD_ACCES
Hi,
This is on Intel OSX, anon CVS download today.
Build process:-
1. make distclean
2. ./configure --enable-debug --enable-cassert --enable-integer-datetimes
--prefix=/Users/grant/Development/bin/pgsql --enable-depend
3. make all install
The query with no EXPLAIN (ANALYSE) completes fine.
Alvaro Herrera wrote:
Tom Lane wrote:
Log Message:
---
Make large sequential scans and VACUUMs work in a limited-size "ring" of
buffers, rather than blowing out the whole shared-buffer arena. Aside from
avoiding cache spoliation, this fixes the problem that VACUUM formerly tended
to cau
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
>> shared_buffers again was 32MB so all the data was in memory.
>
> The case where all the data is in memory is simply not interesting. The cost
> of TOAST is the random access seeks it causes. You seem to
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> shared_buffers again was 32MB so all the data was in memory.
The case where all the data is in memory is simply not interesting. The cost
of TOAST is the random access seeks it causes. You seem to be intentionally
avoiding testing the precise thing we
> > However, it suddenly struck me that we could
> >probably make most of the problem go away if we put that same wait
into
> >DROP DATABASE itself --- that is, if we see other backends in the
> >target DB, sleep for a second or two and then recheck before erroring
out.
Yup, waiting in drop da
Ühel kenal päeval, K, 2007-05-30 kell 21:41, kirjutas Rodrigo Sakai:
> Hello,
>
>
>
> I’m developing an application that needs a different data type. So,
> I have implemented this new data type inside postgresql using C, as
> documentation shows to.
>
>
>
> Basically, the data type is
35 matches
Mail list logo
