Hi,
> The question is that since this enhances the UPDATE syntax, what changes
and
> where all they need to be made with respect to the documentation?
Documentation is the very least of your worries. What exactly is your
implementation plan? If this were a simple or narrow fix it would
have
NikhilS <[EMAIL PROTECTED]> writes:
> I have coded up a patch which solves the following TODO. I will submit a
> patch for this soon:
> http://archives.postgresql.org/pgsql-hackers/2006-07/msg01306.php
Cool...
> The question is that since this enhances the UPDATE syntax, what changes and
>
Hi,
I have coded up a patch which solves the following TODO. I will submit a
patch for this soon:
- UPDATE
- Allow UPDATE tab SET ROW (col, ...) = (SELECT...)
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01306.php
The question is that since this enhances the UPDATE sy
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is there a better way than going to time_t and back?
Isn't the standard SQL-level locution
timestamptz + numeric_value * '1 second'::interval
? I'm not sure what would be the most convenient realization
of this at the C level, but please stay a
Is there a better way than going to time_t and back? I am currently
using this:
db->next_worker =
time_t_to_timestamptz(timestamptz_to_time_t(current_time) +
autovacuum_naptime);
(db->next_worker is a TimestampTz, as is current_time.
On Wed, 2007-03-14 at 10:28 -0700, Timothy J. Kordas wrote:
> I would expect for the same data a hash-join with a work_mem of 256MB
> to run faster than one run with 32MB; even if the inner relation is
> only 30MB.
Certainly not for all data, but for some distrubutions yes, probably.
The easiest
"Timothy J. Kordas" <[EMAIL PROTECTED]> writes:
> I would expect for the same data a hash-join with a work_mem of 256MB to run
> faster than one run with 32MB; even if the inner relation is only 30MB.
Once you get to the point where each tuple is in a different bucket, it
is clearly impossible fo
Tom Lane wrote:
If the planner has correctly predicted the number of rows, the table
loading should be about NTUP_PER_BUCKET in either regime. Are you
sure you aren't just wishing that NTUP_PER_BUCKET were smaller?
Maybe I wish NTUP_PER_BUCKET was smaller. But I don't think that's the whole
s
"Timothy J. Kordas" <[EMAIL PROTECTED]> writes:
> Am I missing something about the current implementation ?
If the planner has correctly predicted the number of rows, the table
loading should be about NTUP_PER_BUCKET in either regime. Are you
sure you aren't just wishing that NTUP_PER_BUCKET were
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>
>> Allow the community to drive the inclusion by making it as easy as
>> possible to allow a proactive argument to take place by the people
>> actually using the product.
>
> This seems to be a rather poor decision making process: "Are the users
>
in nodeHash.c, the function ExecChooseHashTableSize() uses two different
methods for determining the number of buckets to use.
the current code looks something like:
if (ntuples * tuplesize > work_mem * 1024)
buckets = (work_mem * 1024) / (tupsize * 10);
else
buckets = ntuples
Joshua D. Drake wrote:
> Allow the community to drive the inclusion by making it as easy as
> possible to allow a proactive argument to take place by the people
> actually using the product.
This seems to be a rather poor decision making process: "Are the users
happy with the new feature? If so,
On Wed, 2007-03-14 at 16:50, David Fetter wrote:
> On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
> > "David Fetter" <[EMAIL PROTECTED]> writes:
> >
> > > CREATE TABLE symptom (
> > > symptom_id SERIAL PRIMARY KEY, /* See above. */
> > > ...
> > > );
> > >
> > > CREATE TABL
David Fetter wrote:
On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
"David Fetter" <[EMAIL PROTECTED]> writes:
CREATE TABLE symptom (
symptom_id SERIAL PRIMARY KEY, /* See above. */
...
);
CREATE TABLE patient_presents_with (
patient_id INTEGER NOT NULL REFERENCES p
On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
> "David Fetter" <[EMAIL PROTECTED]> writes:
>
> > CREATE TABLE symptom (
> > symptom_id SERIAL PRIMARY KEY, /* See above. */
> > ...
> > );
> >
> > CREATE TABLE patient_presents_with (
> > patient_id INTEGER NOT NULL REFER
<[EMAIL PROTECTED]> writes:
> On Wed, Mar 14, 2007 at 03:25:48PM +, Gregory Stark wrote:
>> <[EMAIL PROTECTED]> writes:
>> > On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
>> >> "David Fetter" <[EMAIL PROTECTED]> writes:
>> >> > CREATE TABLE symptom (
>> >> > symptom_id SER
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> 1. Grab the AutovacSchedule LWLock exclusively.
> >> 2. Check to see if another worker is currently processing
> >> that table; if so drop LWLock and go to next list entry.
> >> 3. Recompute whether table needs va
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> But I take Tom's point about most users not knowing if their TZ database
> is usable or not. Maybe we need a tool (maybe on pgfoundry) that will do
> some analysis to find out, if such a thing is possible.
It's not really *that* hard: diff between our
On Wed, Mar 14, 2007 at 03:25:48PM +, Gregory Stark wrote:
> <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
> >> "David Fetter" <[EMAIL PROTECTED]> writes:
> >> > CREATE TABLE symptom (
> >> > symptom_id SERIAL PRIMARY KEY, /* See above. */
>
Joshua D. Drake wrote:
Gregory Stark wrote:
"David Fetter" <[EMAIL PROTECTED]> writes:
CREATE TABLE symptom (
symptom_id SERIAL PRIMARY KEY, /* See above. */
...
);
CREATE TABLE patient_presents_with (
patient_id INTEGER NOT NULL REFERENCES patient(patient_id),
symptom
On Wed, 2007-03-14 at 16:08, [EMAIL PROTECTED] wrote:
> On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
> > "David Fetter" <[EMAIL PROTECTED]> writes:
> > > CREATE TABLE symptom (
> > > symptom_id SERIAL PRIMARY KEY, /* See above. */
> > > ...
> > > );
> > >
> > > CREATE TABL
<[EMAIL PROTECTED]> writes:
> On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
>> "David Fetter" <[EMAIL PROTECTED]> writes:
>> > CREATE TABLE symptom (
>> > symptom_id SERIAL PRIMARY KEY, /* See above. */
>> > ...
>> > );
>> >
>> > CREATE TABLE patient_presents_with (
>> >
Gregory Stark wrote:
> "David Fetter" <[EMAIL PROTECTED]> writes:
>
>> CREATE TABLE symptom (
>> symptom_id SERIAL PRIMARY KEY, /* See above. */
>> ...
>> );
>>
>> CREATE TABLE patient_presents_with (
>> patient_id INTEGER NOT NULL REFERENCES patient(patient_id),
>> symptom_id INTE
Martijn van Oosterhout writes:
> What is the actual problem being solved here? That people expected the
> timezone changes to be picked up automatically? think if you weigh it
> up, that problem is less significant than: ...
One other point is that symlinking to system timezone info will not
cau
Hannu Krosing wrote:
> Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
> Linnakangas:
>> Tom Lane wrote:
>>> At this point I'm feeling unconvinced that we want it at all. It's
>>> sounding like a large increase in complexity (both implementation-wise
>>> and in terms of API ugliness)
On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
> "David Fetter" <[EMAIL PROTECTED]> writes:
> > CREATE TABLE symptom (
> > symptom_id SERIAL PRIMARY KEY, /* See above. */
> > ...
> > );
> >
> > CREATE TABLE patient_presents_with (
> > patient_id INTEGER NOT NULL REFERENC
Andrew Dunstan wrote:
> Martijn van Oosterhout wrote:
> >I think that from a data integrity point of view the current system is
> >the best. At the very least what you propose is a modularity violation:
> >Postgres depending on undocumented private data of another system
> >component.
>
> I don't
Andrew Dunstan wrote:
Martijn van Oosterhout wrote:
I think that from a data integrity point of view the current system is
the best. At the very least what you propose is a modularity violation:
Postgres depending on undocumented private data of another system
component.
I don't think you
Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
Linnakangas:
> Tom Lane wrote:
> > At this point I'm feeling unconvinced that we want it at all. It's
> > sounding like a large increase in complexity (both implementation-wise
> > and in terms of API ugliness) for a fairly narrow use-ca
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> If that assumption is true (and it must be true for us to move
> the chain in pieces), doesn't that mean we don't really need to
> move the RECENTLY_DEAD tuples preceding a DEAD tuple ?
As I've already said several times: they are dead, but at least f
Martijn van Oosterhout wrote:
On Wed, Mar 14, 2007 at 01:13:58PM +0100, Zdenek Kotala wrote:
I don't think to make a symlink is good solution. It generates a lot of
future problem with package update or patching. Configure switch is much
comfortable for packagers/patch makers. In case when ave
Martijn van Oosterhout wrote:
I think that from a data integrity point of view the current system is
the best. At the very least what you propose is a modularity violation:
Postgres depending on undocumented private data of another system
component.
I don't think you can reasonably describ
On Wed, Mar 14, 2007 at 01:13:58PM +0100, Zdenek Kotala wrote:
> I don't think to make a symlink is good solution. It generates a lot of
> future problem with package update or patching. Configure switch is much
> comfortable for packagers/patch makers. In case when average user want
> to compi
"David Fetter" <[EMAIL PROTECTED]> writes:
> CREATE TABLE symptom (
> symptom_id SERIAL PRIMARY KEY, /* See above. */
> ...
> );
>
> CREATE TABLE patient_presents_with (
> patient_id INTEGER NOT NULL REFERENCES patient(patient_id),
> symptom_id INTEGER NOT NULL REFERENCES symptom(s
On Wed, Mar 14, 2007 at 12:07:45PM +1300, Edward Stanley wrote:
> On Wed, 14 Mar 2007, David Fetter wrote:
> > On Tue, Mar 13, 2007 at 05:54:34PM +, Richard Huxton wrote:
> > > David Fetter wrote:
> > > >On Tue, Mar 13, 2007 at 02:21:37PM +, Richard Huxton wrote:
> > > >>David Fetter wrote:
1. What is the functionality of gistplacetopage() function in gist.c
?Can you please give me detail description of this function.
It tries to place index tuple on page. If page hasn't enough space,
gistplacetopage splits page on two or more pages. Number of page to be splitted
depends, basical
Granted, but a configure switch would allow users who want to use OS TZ
file in conjunction with a compiled from source installation. Many
users of OSes with package managers such as Debian or RedHat may, for
whatever reason, want to use a source tarball to install and also use
the OS TZ list.
Tom Lane wrote:
Josh Berkus writes:
Zdenec,
I have following idea:
1) add guc varibale which enable usage of OS time zone files
2) add extra parameters into ./configure script which enable OS TZ
support in the code and get path to OS TZ files.
If we're adding it as a configure-time variable,
I need help in understanding certain things in gist ...
1. What is the functionality of gistplacetopage() function in gist.c ?Can
you please give me detail description of this function.
2. I have left and right buffers with values that I have filled. Now, how do
I write these changes(buffers) perm
Tom Lane wrote:
At this point I'm feeling unconvinced that we want it at all. It's
sounding like a large increase in complexity (both implementation-wise
and in terms of API ugliness) for a fairly narrow use-case --- just how
much territory is going to be left for this between HOT and bitmap ind
> > The advantage of sync_scan_offset is that, in some situations, a
> > second scan can actually finish faster than if it were the only
query
> > executing, because a previous scan has already caused some blocks to
> > be cached. However, 16 is a small number because that benefit would
> > on
Am Mittwoch, 14. März 2007 08:01 schrieb Michael Paesold:
> Is there anything in the SQL spec that asks for such a behaviour? I guess
> not.
I think that the octal escapes are a holdover from the single-byte days where
they were simply a way to enter characters that are difficult to find on a
ke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 13, 2007 at 05:39:05PM +0300, Teodor Sigaev wrote:
> Hmm, hstore + (optionally) functional indexes. Is it answer?
I have used it in a (yet) test system. It works surprisingly well.
Thanks
- -- tomás
-BEGIN PGP SIGNATURE-
Version:
43 matches
Mail list logo
